Is there a cache of .desktop files, and can it be easily cleared?

Help
1

Hello,

I recently had to modify the .desktop files for some flatpak apps in order to get their UI scaled correctly on my laptop’s display. I’ve used .desktop files before to create custom context menu items, and every time I saved those, the changes took effect instantly. However, when editing the Exec key of the .desktop file for a flatpak app, I had to restart my computer before the changes took effect.

Are the .desktop files cached somewhere, and if so, is there any way of clearing or disabling the cache to make modifications like this easier?

1 Like
2

There are the main folder of /usr/share/applications (system-wide) and then you have the ones in your home folder under /home/$user/.local/share/applications/ (user specific).

3

I know where to find .desktop files, thanks! As I mentioned, I have already edited and created several.

In this case I’m dealing with Musescore, a flatpak which has a .desktop file in /var/lib/flatpak/app/org.musescore.MuseScore/current/active/export/share/applications/org.musescore.MuseScore.desktop, which is linked from /var/lib/flatpak/exports/share/applications. I don’t see a copy or link to either of those files in the locations you suggest.

My problem was that changes to the flatpak’s .desktop file only took effect after a restart, which indicates that they might be cached somewhere.

4

I have never looked into what triggers a re-read of /usr/share/applications to make the change almost instantaneous, but I doubt /var/lib/flatpak/exports/share/applications is triggered the same way.

5

Look if there is an ons folder. I had exactly the same issue. The KDE graphical desktop entry tool puts them to the ons subdirectory for any reason so they are duplicated.

6

You are supposed not to edit a .desktop file in place, but to copy the .desktop file to ~/.local/share/applications, and edit it there. KDE’s own menu editor works this way, too.

7

Edit: While the below is still potentially useful, at least as an example of setting a directory watch with systemd, I’ve done additional testing on my part and found that the issue for me has specifically been that if I edit a file using nano, that the cache update is not triggered due to how nano saves files, however using something else like vim or Kate which create/delete temporary files (for me at least) as part of saving does cause the cache update to trigger.

You can try running kbuildsycoca5. As per the man page it “Rebuilds the KService desktop file system configuration cache”.

I don’t know that there’s a watch on the directories for changes, I think it may be that when you install applications that the cache update is triggered (someone more knowledgeable may be able to better inform on this).

The recommendation to put modified .desktop files in ~/.local/share/applications/ I think is a good idea in general since the local .desktop file will override the system one (as long as the .desktop files are named the same), though changes in the local directory don’t seem to get picked up unless the cache is rebuilt (or at least it doesn’t for me).

To that end, for the .desktop files in the home directory, I actually ended up using systemd to watch the path which triggers the kbuildsycoca5 command to run.

To do this, under ~/.config/systemd/user/ create two files:

rebuild-kservice-cache.path (change the [USERHOMEHERE] portion to your home directory):

[Unit]
Description="Monitor ~/.local/share/applications/"

[Path]
PathModified=/home/[USERHOMEHERE]/.local/share/applications
TriggerLimitIntervalSec=5s
TriggerLimitBurst=1
Unit=rebuild-kservice-cache.service

[Install]
WantedBy=default.target

rebuild-kservice-cache.service:

[Unit]
Description="Rebuild the KService desktop file system configuration cache when ~/.local/share/applications/ changes"

[Service]
ExecStart=kbuildsycoca5

Then reload the user systemd manager configuration via:

systemctl --user daemon-reload

And finally enable and start the rebuild-kservice-cache.path:

systemctl --user enable --now rebuild-kservice-cache.path

In theory, you could also change the above path to the home applications folder to watch the /var/lib/flatpak/exports/share/applications/ directory instead, but I’d recommend trying to copy the .desktop file to the relevant home directory first, that way you shouldn’t have an issue if an update changes the system shortcut.

2 Likes
8

Thanks a lot for the detailed response! I will store modified .desktop files in ~/.local/share/applications in the future, and set up that folder watcher. Do you think it would be worth filing a feature request to have that folder watched by default?

9

Do you think it would be worth filing a feature request to have that folder watched by default?

Yeah, I think that’s worth considering. Edit: As per @nicolasfella, the actual issue should be raised as a bug.

10

Please report problems, not solutions. i.e. describe what you are doing that should work but doesn’t, not how you think it should be solved

1 Like
11

Please report problems, not solutions. i.e. describe what you are doing that should work but doesn’t, not how you think it should be solved

My bad, that’s a good point, so really it’s not a feature request for something, it’s an issue where the expectation is that changes to .desktop files in ~/.local/share/applications/ (or even new .desktop files) should automatically be reflected when launching from whichever application launcher without having to manually run kbuildsycoca5.

Which component/product should the bug be raised against. Is this a frameworks-kservice issue or would something else be more correct?

12

You might want to use the --noincremental option to the kbuildsycoca5 command. This makes it fully reset the cache each time the command is used, rather than lazily over time.

13

It looks like there’s already a bug related to the issue, though it was in the vein as you’d noted of suggesting the the solution rather than noting the issue.

1 Like
14

Good find! I replied there with a problem-oriented description of what happened in my case.

15

As many people are in this thread I would like so solve:

What the hell is ~/.local/share/applications/ons ?

This is the directory kmenuedit (The Graphical .desktop entry editor) saves new entries, at least on Fedora KDE. The result is, if you already have that entry in ~/.local/share/applications, that weird things happen and they coexist or are not overwritten

16

I have a theory for what might be happening.

If .local/share/applications doesn’t exist yet then it might not be watched for file modifications and thus the database would not be rebuilt once you create it and change something there.

I wasn’t able to reproduce it that way though

17

David Faure noted in the bug report that there is meant to be a watch on the directory and recommended checking debug output, so I did more testing and added information to the bug in case it helps, but it seems like it’s how the files in the directory are watched that factor into the problem, for me at least.

The information I added to the bug provides more detail, but how it seems to me is that nano writes direct to the file and doesn’t trigger a cache update, whereas copying a file into the directory, or any other files being created/deleted in the directory trigger the cache update. This also means using another editor which creates temporary files as part of the save process will trigger the update.