Request for clarification on menu/file spec

[Jeremy White]

> If there is concensus that that is the right long term direction and that the 
> benefits outweigh the disadvantages then I guess we should go that way. I 
> would like to hear some more cheers of support for that direction first 
> though.

You can consider this another -1 vote.

IMHO, the current menu-spec is nearly perfect.  It is simple,
comprehensible, and requires no 3rd party tools in order to
implement it.  It just needs a minor clarification and
we'll be good to go.

Yes, isolation of all files into their own directory is an
admirable goal, but I don't see that happening.  Further, if
we isolate into /usr/local/share/applications, the pollution
is kept to a minimum, and the simplicity of how menus work
is maximized.

Finally, I did some further research, and my earlier comments
were not quite accurate.  I looked at SuSE 10, Fedora Core 4,
and Ubuntu 5.10.

Broadly, I found that /usr/local/share/applications did not
exist on stock installs of any of these distributions.
Only SuSE 10 had an explicit XDG_DATA_DIRS; the rest had
none defined; I used the presumed default of /usr/local/share and /usr/share.

On SuSE (Gnome and KDE) and Fedora Core Gnome, if I created
a /usr/local/share/applications directory and put my .desktop
file into it, it worked just as I expected, and there was
much rejoicing.

On Fedora Core 4 KDE and Ubuntu 5.10 (Gnome only), creating
/usr/local/share/applications and putting a .desktop file
there had no effect at all.  No joy in Mudville whatsoever.
Moving the .desktop file to /usr/share/applications worked fine.

My earlier tests were on Debian/etch and had much the same
result as that of Ubuntu (that was on my laptop, which is at home, so I can't
easily reproduce it atm).

Hence, I am willing to be persuaded that the first directory
in XDG_DATA_DIRS is the appropriate spec, although I retain
a fondness for the first existing and writable directory, just
because that's how I'm going to implement my code anyways :-/.

Cheers,

Jeremy