Request for clarification on menu/file spec
bastian at kde.org
Wed Feb 8 01:29:47 EET 2006
On Tuesday 07 February 2006 09:31, Thiago Macieira wrote:
> Jeremy White wrote:
> > The whole problem is when you say 'try $XDG_DATA_DIRS', what
> >exactly does that mean? I'm trying to write a single .desktop file;
> >do I write it to every directory listed in $XDG_DATA_DIRS? Do I write
> >it just to the first directory, or do I (my personal favorite) write
> >it to the first writable directory in the list?
> >Note that I'm actually not waiting on this; my implementation is done
> >and works. My concern is that I want to improve the specification so
> >that others can find it simpler to do this in the future.
> A self-contained package should not install stuff outside its prefix. So,
> if the user says it should install under /opt/appname, there should be
> nothing in /usr. That's what I would expect, at least.
Yes, and that's what LSB says as well. Unfortunately that doesn't get your
application in the menu. So there is a bit of a disconnect here.
> Now, if you want to have the menu entry show always, you should add it
> to /usr/share/applications. If XDG_DATA_DIRS does not point to /usr at
> all, it's because the user chose that way.
Well, adding to /usr/share/applications is certainly a solution, I'm not sure
it is The Right Solution (tm) Based on the spec, it is reasonable to expect
that both /usr/local/share/applications as well as /usr/share/applications
can be used.
I'm inclined to think that /usr/local/share/applications should be preferred,
given that /usr/share/applications can be read-only.
Unfortunately that is rather at odds with Jeremy's observation
that /usr/local/share/applications doesn't seem to work.
> You'll probably need to make your application be instead a script that
> sets PATH and LD_LIBRARY_PATH and other variables, as necessary.
That doesn't gets you your application in the menu. Ajusting XDG_DATA_DIRS at
that point will not have any effect on the menu.
> But note that, as I said, it may be difficult to interoperate in the
> future if you run an app that expects the system to find stuff that is
> outside XDG_DATA_DIRS (e.g., systray app telling the systray to show icon
Right, the oldest manifestation of this problem is with man-pages. One of the
solutions there is to adjust /etc/man.config Unfortunately there is no
similar mechanism for XDG dirs and if there was it may have a rather
undesired effect on the length of the typical search path.
See also http://bugs.linuxbase.org/show_bug.cgi?id=858 and
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060207/886f21ca/attachment.pgp
More information about the xdg