desktop_entries: Reload .desktop on search #269
Conversation
ljrk0
force-pushed
the
desktop-entries-rebuild
branch
from
387a8b8 to
debc2f7
Compare
Since pop-launcher has been demonized, the desktop_entries plugin isn't relaunched on every search anymore. In consequence, it is not providing up-to-date results when .desktop files have changed (e.g., on un-/installation of a new application) anymore. Move the app.reload() call into the request loop to trigger a re-index. In a release-build this has been fine performance wise on an 8th Gen i5 laptop device. As a small performance improvement, only trigger this update on a search event and if the search query is empty. Alternatives could include remembering the last time the index was built (initialised to UNIX_EPOCH before the loop) and only conditionally triggering a re-index after a hot-period of 10s since the last run. In our testing this didn't result in any noticeable difference.
ljrk0
force-pushed
the
desktop-entries-rebuild
branch
from
debc2f7 to
cfaa866
Compare
|
Implemented the requested change + rebased ontop of The new behavior seems that the But it seems that the If I understand this correctly, then this PR can be closed? |
|
iirc, a plugin will only be "demonized" when they have long_lived in their manifest (ex: cosmic_toplevel, https://github.com/pop-os/launcher/blob/master/plugins/src/cosmic_toplevel/plugin.ron#L7). |
|
You could also add a watcher on the .desktop dirs. Idk if its better performance wise |
Since pop-launcher has been demonized, the desktop_entries plugin isn't relaunched on every search anymore. In consequence, it is not providing up-to-date results when .desktop files have changed (e.g., on un-/installation of a new application) anymore.
Move the app.reload() call into the request loop to trigger a re-index. In a release-build this has been fine performance wise on an 8th Gen i5 laptop device.
Alternatives could include remembering the last time the index was built (initialised to UNIX_EPOCH before the loop) and only conditionally triggering a re-index after a hot-period of 10s since the last run. In our testing this didn't result in any noticeable difference.
NOTE: This has been tested against commit fca3b25 but builds against master too. However, master error'ed with unrelated issues regarding the parsing of CLI arguments.