SUMMARY Hidden=true is not handled correctly WRT desktop files that appear in multiple xdg_data locations STEPS TO REPRODUCE 1. have a valid /usr/share/applications/foo.desktop 2. copy to /usr/local/share/applications/foo.desktop 3. add Hidden=true to the copy 4. kbuildsycoca5 --menutest |grep foo.desktop OBSERVED RESULT foo.desktop is in the menu EXPECTED RESULT foo.desktop shouldn't be in the menu https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html describes the file locations for searching `$XDG_DATA_DIRS/applications/` as > This directory contains a .desktop file for each possible menu item. > Each directory in the $XDG_DATA_DIRS search path should be used (i.e. > desktop entries are collected from all of them, not just the first one > that exists). **When two desktop entries have the same name, the one > appearing earlier in the path is used.** https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html describes Hidden as > Hidden should have been called Deleted. It means the user deleted > (at his level) something that was present (at an upper level, e.g. in > the system dirs). It's strictly equivalent to the .desktop file **not > existing at all, as far as that user is concerned.** The language is a bit ambiguous but to me that reads like the intent here is that if a file is marked Hidden it definitely shouldn't show up anywhere or even be used for mimetype resolution and the likes, even when a later xdg_data location offers the same desktop file. This is also how gnome behaves here, the aformentioned example works as expected there. The way I'm reading the current implementation of kbuildsycoca that is not how we do things though. Specifically KServicePrivate::init sets the service deleted when it reads Hidden=true and then KBuildServiceFactory::createEntry returns nullptr when the service was marked deleted. This effectively skips the entry leaving a higher level entry to take its place (as per the menu spec I quoted above). Put together that means kservice applications offer no way to set a desktop id Hidden=true as a version of foo.desktop appearing in any of the directories is enough to override the Hidden one.
Hi. This bug is nearly two years old, and has become an actual problem now due to the advent of immutable distros where there are actual good reasons to hide system applications. For example, we are currently struggling with the fact that the Firefox included in SteamOS--an immutable distro included on the Steam Deck, which ships Plasma--is six versions behind. We need to be able to provide instructions to hide that version without disabling the OS's immutability, and rely on the one from Flathub until Valve changes their system image to rely on Flathub's build of Firefox. We should be able to copy firefox.desktop to `~/.local/share/applications` and make changes to it to hide it, but it doesn't work because of this incorrect behavior. It seems like we can get the system Firefox to disappear from the Internet section of Kickoff with `Hidden=true`, but it still appears if you search for it, and it is still offered as a default web browser. It seems a lot of other behavior that should allow it to at least be disambiguated doesn't work. I wanted to change the shortcut's name to "Firefox (System)" to at least differentiate it from the Flatpak, but that name change is entirely ignored for no discernible reason. I came looking to see if that was a reported bug, and instead found this bug report. It could be possible that a lot of override handling is straight up broken right now, not just Hidden handling.
>until Valve changes their system image to rely on Flathub's build of Firefox This has happened. (and we have an out of date KDE on that device so any changes won't work) >We need to be able to provide instructions Who is "we" in this context?