Menu spec update (summary; closure?)

[Joerg Barfurth]

Lennon Cook wrote:
> On 3/24/06, Waldo Bastian <bastian at kde.org> wrote:
>> Just like #3,  the application could install all its files within its own
>> prefix.
> I tend to think that this is the best idea. 

The problem is that it complicates things for users that simply want
newly installed applications to be in their menu. They always have to
take extra steps. As Waldo has mentioned it also may have a performance
impact (it leads to long XDG_*-DIR search pathes, requiring iterating
all those directories.

>> The tool could probably symlink the files
>> into /usr/share/applications with the option to use other locations at the
>> discretion of the distributor.
> Leave decisions like this to the user/sysadmin/distro. 

The idea of such a tool is, that it is a well-defined interface (i.e. we
fix its name and syntax), but multiple implementations are possible. The
distributor can choose to create an implementation that uses the
location of their choice. And they can even add support for
admin-provided policy. That means the admin can make this a no-op or
redirect to a special directory through a file in /etc. And the admin
can use the same tool for menu integration of bits that are already
installed in a shared location.

> What happens
> if, for whatever reason, the sysadmin doesn't want a particular app's
> files to be in the various paths? The installer has no way of knowing
> this. The policy of how to include a particular file in XDG_*_DIRS
> directly affects this, and so should be an admin concern.
> 

The implementation of the tool may provide this capability.

So I think the tool idea really provides the best of all worlds. All the
better, if there is a desktop-install tool precedent.

- Jörg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
Thin Client Software