search

abenz1267 / walker

Application launcher similar to Rofi etc. . Wayland native.
MIT License
263 stars 12 forks source link

Walker can't find new applications #39

Closed ItsDrike closed 1 month ago

ItsDrike commented 1 month ago

Currently, it seems that walker is caching the discovered .desktop applications in ~/.cache/walker/applications.json. This cache doesn't seem to be getting updated though, which means that if walker was installed before some other application, walker won't discover this new applications, unless this cache is manually deleted.

Perhaps walker could instead perform some kind of check each time it's started, just going over the directories that contain these .desktop appliation files, checking that there's no new entries. (Even just a hash based check of some kind would probably be sufficient).

I don't mind having to delete this cache file too much, however it could be confusing for people that aren't aware that this file exists and just aren't seeing newly installed applications, without knowing why. I don't mind if you make this a wontfix, but it should definitely be documented (at least in this github issue, but ideally in the readme too), for people that don't know about this caching behavior. That said, unless it would greatly increase startup times, I do think that it's a good idea to add this check.

abenz1267 commented 1 month ago

You can disable the cache by setting 

  "applications": {
    "disable_cache": true
  }

On my system I didn't notice any performance-issues that would make me turn on the cache again.

I'll think about if it's even worth adding such a check... although i feel like it'd defeat the purpose of the cache (in terms of performance) and simply disabling it would result in the same (or nearly the same) performance.

Edit: You can clear the cache via the commands module as well. It has a special "Clear Applications Cache" command.

ItsDrike commented 1 month ago

Ah I didn't know about the command or the disable option, that's good to know, perhaps the cache should then be completely opt-in, or even just removed, if there's no real performance cost to it? Or do you think that in some systems, it might be a different story (i.e. hdd systems where finding the applications might take longer or something)?

abenz1267 commented 1 month ago

I don't know about the performance impact on slow hardware, but I agree it should possibly be opt-in rather than opt-out by default.