NoDisplay interpretation
Mark McLoughlin
markmc at redhat.com
Mon Oct 4 19:34:53 EEST 2004
Hi Waldo,
On Fri, 2004-10-01 at 14:09, Waldo Bastian wrote:
> On Friday 01 October 2004 14:39, you wrote:
> > A contrived example of when it makes a difference is when you have
> > duplicated .desktop files. If the first .desktop file found contains
> > NoDisplay=true, but the duplicate .desktop file contains
> > NoDisplay=false, you'd expect the entry to not appear in the menu.
> >
> > However, if you consider the same example with Hidden=true, you
> > actually *would* expect the entry to appear in the menu since the first
> > .desktop file would not preclude the second .desktop file from being
> > considered. Right?
>
> It depends on what you mean with "duplicated .desktop files". If they are in
> the same relative location in the hierarchy, (e.g.
> ~/.kde/share/applnk/foo.desktop and /usr/share/applnk/foo.desktop) they get
> merged on a key by key basis and then after the merging we look at the
> resulting Hidden and NoDisplay values.
But isn't this the opposite of what the spec says?
$XDG_DATA_DIRS/applications/
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.
I'm not sure why you'd merge on a key by key basis - it makes removing
a key impossible, for example.
Cheers,
Mark.
More information about the xdg
mailing list