I've run into weird issues with the menu (old application path being launched) caused by the fact that Plasma hadn't reindexed it. They were solved by running `kbuildsycoca5`. It would be helpful to have a button that essentially runs that command.
Let's focus on the issue that's prompting you to look for this proposed solution, rather than the proposed solution itself. See https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution. In general KMenuEdit is supposed to run `kbuildsycoca5` after every save operation, so if this isn't working, we should investigate why and fix it. Can you talk a bit about the situation in which the menu had state contents such that manually running `kbuildsycoca5` fixed it? How did you make this happen?
Created attachment 156246 [details] File that was not read by the menu editor One issue is that I copied the attached `zalc.desktop` file to ~/.local/share/applications, and the shortcut is not visible in the KDE Menu Editor, but is visible when I search for "zalc" in the launcher. Copying that .desktop file also made it impossible to find LibreOffice 7.4 Calc in the launcher when I search for "calc" - only "Zalc" appears. (After moving the file away then moving it back to ~/.local/share/applications, the problem seems to have resolved itself.)
I think this situation falls into the "I know just enough to hurt myself" valley. :) If you know the technical details about what .desktop files are and the hidden location where they live, it's expected that you also know to run kbuildsycoca5 manually (or just restart the system) after making changes. If you don't know to do that, then the expected UX is to use KMenuEdit, which handles running kbuildsycoca5 for you. One think we might be able to do is to watch for manual changes to ~/.local/share/applications such that kbuildsycoca5 gets run automatically when there are any changes. We already do something like this in kded for new icons, so maybe it would be reasonable to do it for .desktop files too. Moving to KDED for evaluation.
I ran into the same issue recently when making a custom .desktop file to open an application with the correct UI scaling for my screen. My problem-oriented summary of the issue would be as follows: When moving, saving or otherwise updating a .desktop file in ~/.local/share/applications, I expect the DE to automatically detect the change and update itself, exactly as it does when adding custom service menus in ~/.local/share/kio/servicemenus. In my case, adding and changing a .desktop file in ~/.local/share/applications had no immediate effect, and (not knowing about kbuildsycoca5 and not being able to find any GUI for refreshing a cache) I had to reboot my computer for the changes to take effect.
(In reply to Nate Graham from comment #3) > I think this situation falls into the "I know just enough to hurt myself" > valley. :) > > If you know the technical details about what .desktop files are and the > hidden location where they live, it's expected that you also know to run > kbuildsycoca5 manually (or just restart the system) after making changes. If > you don't know to do that, then the expected UX is to use KMenuEdit, which > handles running kbuildsycoca5 for you. In the case of Dolphin context menus, this is not the case according to the documentation: https://develop.kde.org/docs/apps/dolphin/service-menus/, which proudly (and, for context menus, correctly) states “you don't need to be a software developer to create new actions”. kbuildsycoca5 isn’t mentioned on the entire page. Presumably the folders for context menu .desktop files are watched and automatically updated, which led me to assume that all common locations for .desktop files are similarly watched and updated.
~/.local/share/applications isn't "watched" (in the sense of inotify) (we used to do that, and it was a lot of trouble due to inotify limits (kdevelop or qtcreator easily used up all inotify watchers) -- plus, what if the change happens while not in Plasma...). Instead the directory timestamps are compared with the cache's timestamp any time the cache is used (i.e. "on demand"). This happens when e.g. clicking on a file and we have to find out which app to launch -- the cache will be updated first. This makes the solution very robust. Dolphin's code is surely similar: upon opening the context menu, it first checks for changes. But I'm not sure about the case of the K menu, I didn't work on that part. If it's all about the K menu, then the bug needs to move to plasma (well, unless the plasma people are counting on KDE Frameworks for this, but hopefully not - I vaguely remember something about updating this when opening the K menu, based on timestamps again, which would be the right time to do so....)
Actually, kded5 does appear to install a watch on that directory (among others), in readDirectory(). I wonder if that's what plasma is relying upon. Probably. If I touch a desktop file in that directory, I see debug output from kded5 appearing right away. at least stuff like "kded module [...] is already loaded". Do you see that too? Enable the debug area kf.kded in the kdebugsettings application first.
(In reply to David Faure from comment #7) > If I touch a desktop file in that directory, I see debug output from kded5 > appearing right away. at least stuff like "kded module [...] is already > loaded". Do you see that too? Enable the debug area kf.kded in the > kdebugsettings application first. I enabled debug output for KDED and I do see the "kded module [...] is already loaded". This output triggers whenever I change a file in "~/.local/share/applications", but I've discovered some interesting things as part of testing this just now. I don't know if the behavior I'm testing will be the same for others, but it's what has happened for me and it seems to relate to using "nano" to edit the desktop files. In all of the testing that I've been doing, I've been using nano in a terminal to edit my .desktop files and changes made that way has worked as expected using GNOME (from what I remember). When I change a .desktop file with nano, the KDED debug output is displayed, but the change is not reflected in the applications menu, which I take to indicate that kbuildsycoca5 hasn't run. If I use Kate or vim to edit the file instead (the only other editors I've tested so far), I still get the same KDED debug output, but the change actually is reflected in the applications menu, which I assume means that kbuildsycoca5 has actually run this time. Is there something different in the way nano saves files which could be relevant here? If I save a new .desktop file in the applications directory, that triggers an update, so I could change one .desktop file with nano, copy in another .desktop file entirely and it will trigger an update. Similarly, if I copy a .desktop file over the top of the existing file it will trigger an update, which means that I could edit a file with nano, copy the file elsewhere and then copy it over the top of the existing file and again, an update is triggered. So at least for me, it looks like it's generally working as expected UNLESS I edit an existing file with nano. Again, I don't know if others will get the same behavior, but that's what my testing has shown so far.
I've done some additional testing that may help provide more useful context. Looking into how nano saves files, I'm wondering if the way the "~/.local/share/applications" directory is watched, or how the files in the directory are watched, has an impact here. I had a look at the source and saw references to KDirWatch so I enabled Full Debug (via KDebugSettings) for both KDirWatch and KDED and did more testing to see what output I would get. As I understand it, when nano saves a file it overwrites the file directly, so I expected debug output there, but got nothing on saving the file. Testing with Kate, I checked my settings and under Open/Save > Advanced, the "Swap file mode" is set to "Enabled, Store In Default Directory", and when saving, it creates a temporary "kate-swp" file in the same folder and then deletes it (it also creates the swap file if you start making changes), events which show up in the debug output, along the lines of "kf.coreaddons.kdirwatch: 1 instance(s) monitoring the new file <filename>" and then "kf.coreaddons.kdirwatch: "KDirWatch-XX" emitting [created/deleted] <filename>", and those events trigger the update. Testing with vim, there are similar events, but vim saves to a temporary file first and then I assume it moves/saves the modified file in place of the existing file, which also triggers the update. With the above information, I've also tested nano by turning on the "set lockfile" setting which creates a ".swp" file when you open, but won't delete the swap file on saving (without exiting), however if you make another edit after saving it will delete the old swap file and create a new one, which will trigger the update, or once you exit, either "exit and save" or just exit after saving manually.
Well done for this investigation. I think it's all about whether the modification time of the directory gets updated (which is the case when creating a temporary file, but not when overwriting the desktop file directly). Note that most KDE software creates a temporary file via QSaveFile when saving too, not just the swp file (this is in order to rename the file atomically at the end of the write, to avoid losing everything if the partition is full). But clearly nano doesn't do that... Code pointer: KSycocaPrivate::needsRebuild() in kservice calls checkDirectoriesTimestamp which looks at the timestamp of directories (and compares them with the time in the database header, coming from readSycocaHeader()). We could look at the timestamp of every single file, but this feels quite slow, for a rare "editing with a broken command line tool" scenario... (broken because it would lose everything if the partition is full)