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.
