https://bugs.kde.org/show_bug.cgi?id=424716
Bug ID: 424716 Summary: Hidden=true handling incorrect Product: frameworks-kservice Version: 5.72.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: fa...@kde.org Reporter: sit...@kde.org CC: kdelibs-b...@kde.org Target Milestone: --- 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. -- You are receiving this mail because: You are watching all bug changes.