Subject: Re: automatic menu entries (was Re: Alternatives system, 2nd round)
To: Jeremy C. Reed <reed@reedmedia.net>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: tech-pkg
Date: 01/21/2005 23:20:29
On Fri, 2005-01-21 at 13:48 -0800, Jeremy C. Reed wrote:

> make_desktop_entry /path/to/executable Icon-name /usr/share/pixmaps/foo/icon.png Category /optional/startup/path
> 
> All it does is generate a /usr/share/applications/ desktop file:
> [Desktop Entry]
> Encoding=UTF-8
> Version=0.9.2
> Name=${name}
> Type=Application
> Comment=${DESCRIPTION}
> Exec=${exec}
> Path=${path}
> Icon=${icon}
> Categories=Application;${type};
> 
> (DESCRIPTION would be our COMMENT.)

Add MimeType too!

However, I was thinking on something easier.  Just storing the .desktop
file in the files dir and processing/installing it automatically as done
with the rc.d scripts.  This'd have the advantage of being able to add
new lines at will to specific packages (say localized comments, which
may be good).

> Providing .desktop files will be the easiest and better for handling more
> features and languages.

Indeed.

> > GNOME and KDE support could come for free.  For other window managers,
> > we'd need a tool that does the same as the major desktop do (read the
> > .desktop files and construct the menu).  I don't know if there is any
> > such program already, but if it's not, I think it may not be that hard
> > to implement if we reuse some of the existing code.
> 
> One is
> http://sourceforge.net/projects/vfmg which generates many menu formats
> from the freedesktop.org (XDG) menu specification.
> 
> Maybe the  desktop-file-utils package can help too.
> 
> And maybe http://www.freedesktop.org/software/pyxdg/ and
> http://freedesktop.org/wiki/Software_2fpyxdg  (URL has typo in it probably
> due to recovery of wiki)

Cool :)  Didn't know these tools, but as they already exist... it's
another point in favor of this approach.

> We could have each of our window manager packages provide a script to
> handle the generation of their own menus -- stored in SYSCONFDIR.
> 
> Then another package to provide a script that when ran will run all the
> other scripts that are installed. For example, no icewm menus are
> generated if only openbox is installed.

I think it'd be easier to simply have a wm.d directory where each wm
could place its generation file.  Then, at install time, run all the
scripts found in that directory.

SYSCONFDIR/wm.d exclusively seems incorrect to me though.  We should
first look there, but then fall back to a directory under PREFIX, say
PREFIX/share/wm.d.  How?  First construct a list of wms based on all
the files available under the prefix directory.  Then, for each item,
see if there is one with the same name in the sysconfdir.  If found,
run it; otherwise, run the one in prefix.

This can be easily done from an INSTALL script, shared by all
packages that provide .desktop files.  Then you'd have transparent
handling of all the wms.

(Of course, the installation of a specific wm should also trigger
the execution of the files.)

> Do we need to make sure that all .desktop files are installed to one
> place? (Do we have different /usr/pkg/gnome/apps/ and
> $KDEDIR/share/applnk/ directories? I should look ....)

/usr/pkg/share/gnome/apps is deprecated.  All the stuff now goes into
share/applications (referred by XDG_DATA_DIRS [1]) and each file
classifies itself by its Categories entry.

Dunno what KDE will do, but using a single directory seems simpler,
easier to parse and to manage.  But as long as the files have the
Categories property, it doesn't really matter where they are; you
can read them from many places and merge them in the same menu.

Cheers,

[1] Please, don't get me started on the XDG spec...

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/