Why the AppsScanInterval?

[friday]

Really nice work on Catapult 👍 I'm the current maintainer of Ulauncher, and stumbled into Catapult on the AUR. Since Catapult was built with very similar purpose and tech stack as Ulauncher it was interesting to look under the hood :) I've been making a lot of effort to get Ulauncher more performant and minimalistic in the upcoming major release, so it'll actually be more similar to Catapult (but definitely not as performant or minimalistic as Catapult, because of our extension API, process isolation and web-based preferences).

Anyway, one thing I don't understand is the AppsScanInterval in the apps plugin. When you install an app as Catapult is running, there's a timer (defaulting to 15 minutes and min value 1 minute) until it updates. I know you can reload the plugins, but that's the sort of thing that confuses new users. Have you tried actually measuring how much of a performance bottleneck it would be to just reindex instantly? Unless I'm very mistaken Gio.AppInfo.get_all() doesn't do anything resource intensive like indexing files. It just returns a cache. Ulauncher v6 even runs it on every keypress, so I think I would have noticed if it was slow.

[otsaloma]

Thanks, I've been following Ulauncher. When I finally chose to write my own launcher I did take a closer look at the Ulauncher code base, but found many parts of it too complicated and chose to copy only some things like how to do theming, how to setup a global keybinding, how to show or hide the window when the global key is pressed etc.

Regarding the scan interval: I haven't measured it at all, I have just assumed it has to actually scan the desktop file directories. But I guess I could check, I have a hook that can be run by the plugin when showing the window, which could be used here. I don't see anything in the documentation on how AppInfo actually works.

I'm also using the AppInfoMonitor, but at least on my system that doesn't seem to fire:
https://github.com/otsaloma/catapult/blob/master/catapult/plugins/apps.py#L64-L65

[friday]

I think you made the right call to start from scratch. I couldn't have done the same when I took over the maintenance, because I lacked the GTK experience. But I'm sure I spent more time refactoring Ulauncher than it would have taken to write from scratch if I had that experience. There's a lot left to improve too, but you can't move very fast without breaking compatibility and tests.

The AppInfoMonitor event doesn't fire for me either. I never checked that (just assumed it worked).

AppInfoMonitor documentation says this:

In the usual case, applications should try to make note of the change (doing things like invalidating caches) but not act on it. In particular, applications should avoid making calls to GAppInfo APIs in response to the change signal, deferring these until the time that the data is actually required. The exception to this case is when application information is actually being displayed on the screen (eg: during a search or when the list of all applications is shown). The reason for this is that changes to the list of installed applications often come in groups (like during system updates) and rescanning the list on every change is pointless and expensive.

I never read this before, but it's similar to your implementation and reasoning. However, you are still running Gio.DesktopAppInfo.search() on every keypress, and that searches the same entries as Gio.AppInfo.get_all() It wouldn't be that much overhead to implement your own search on top of Gio.AppInfo.get_all(). Then you could add support for searching tags, custom weighting and fuzzy searching too eventually.

If you know C (I don't), this is what they do (get_all is listed just below search): https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdesktopappinfo.c#L4701-L4837

[otsaloma]

Gio.AppInfo.get_all() seems to take just 20–30 ms on my system. I can't tell from very long C code, but I guess Gio is using a file monitor on the desktop directories and get_all() then returns from the some in-memory list that the monitor updates. Seems fast enough, so I'll change the indexing so it's run once every time when the launcher window is shown.

The mentions in the documentation about being "expensive" could also refer to Windows or Mac, where they might have a different setup, but I don't need to worry about that.

Thanks for noticing, this should be a lot better.