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.

Reply via email to