Draft: Add a trigger file for running kbuildsycoca5 when desktop files change.

[jpwhiting]

Tells kde/plasma to update it's database of .desktop files, icon
caches, etc.

[smcv]

From discussion elsewhere, but should be clarified in the commit message:

This is a KDE equivalent of the GLib and GTK icon and .desktop file caches that we already have triggers for, and we want to update its caches for the same reasons.

[smcv]

What files does kbuildsycoca5 read as input? Whatever those files are, we need to be triggering it whenever there's a change to their directories: so at least the .desktop files you're looking at already, but possibly also e.g. icons in share/icons.

If you happen to be using KDE on a Debian-based system like Kubuntu, you could look for KDE things in /var/lib/dpkg/triggers/ to find out what the analogous dpkg triggers are. Other packaging systems have equivalents that you could use as a reference, but I don't know where they are specifically.

[jpwhiting]

What files does kbuildsycoca5 read as input? Whatever those files are, we need to be triggering it whenever there's a change to their directories: so at least the .desktop files you're looking at already, but possibly also e.g. icons in share/icons.

If you happen to be using KDE on a Debian-based system like Kubuntu, you could look for KDE things in /var/lib/dpkg/triggers/ to find out what the analogous dpkg triggers are. Other packaging systems have equivalents that you could use as a reference, but I don't know where they are specifically.

https://userbase.kde.org/KDE_System_Administration/Caches has some details, but mostly it searches the xdg paths, etc.

Just pushed an update to run if any of those 3 directories exist. Since it caches some details from each (desktop files, icon cache, and mime types) according to the man page.

[smcv]

This needs adding to dist_triggers_SCRIPTS in Makefile.am.

[smcv]

When installed to the same directory as the other triggers, does this successfully rebuild the cache when you add/remove Flatpak apps? I've seen discussion elsewhere that suggests it might not.

If it doesn't seem to be working, it might help to add debug logging like

logger -t flatpak-kbuildsycoca.trigger "Rebuilding cache for change to $1 with XDG_DATA_DIRS=$XDG_DATA_DIRS"

and look for the resulting messages in the systemd journal (but please don't include that logging in this PR).

[jpwhiting]

In testing I'm finding that this doesn't do what I had hoped. Working on it.

[davidedmundson]

Tells kde/plasma to update it's database of .desktop files, icon caches, etc.

Just to clarify it will only handle .desktop files and rebuilding of menus.

We already have a dir watch on the relevant folders which will fire after a flatpak app is installed, albeit after a small delay. This will save the user a few seconds, but it's not especially important. Within KDE that timeout can probably be reduced.

We do have an icon bug (which I suspect triggered this) where we don't handle a new hicolor directory first appears at runtime. That might be worth a flatpak-specific solution as it's not a situation that occurs with other types of packaging.

[jpwhiting]

Tells kde/plasma to update it's database of .desktop files, icon caches, etc.

Just to clarify it will only handle .desktop files and rebuilding of menus.

We already have a dir watch on the relevant folders which will fire after a flatpak app is installed, albeit after a small delay. This will save the user a few seconds, but it's not especially important. Within KDE that timeout can probably be reduced.

We do have an icon bug (which I suspect triggered this) where we don't handle a new hicolor directory first appears at runtime. That might be worth a flatpak-specific solution as it's not a situation that occurs with other types of packaging.

Yeah, what should/could flatpak do to trigger the icon cache (and what's it called by the way? something in Qt itself or part of kded or something?)