Subject: Desktop files
To: None <>
From: Julio M. Merino Vidal <>
List: tech-pkg
Date: 01/27/2005 13:37:40
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi all,

based on a recent discussion, I would like to start adding .desktop
files to several graphical applications that do not include them.  This
can be done now; we can deal with the deatils on how to generate menu
entries for specific window managers later in the future without

To simplify this process, I've created a file, included by when needed, which does a very similar task to RCD_SCRIPTS
(in fact, it's almost copied verbatim).  I.e., you define a
DESKTOP_FILES variable with the list of desktop files to install, which
are then read from ${FILESDIR}, processed with SED and installed into
the right place.

First, let me say that generating .desktop files based on some make
variables (like Gentoo does) is not a good idea, IMHO.  The reason is
that the structure of these files may heavily vary from one to another,
so the make constructions could be incomplete and too complex.  E.g.,
the name/comment entries can be translated into multiple languages
(something we probably want to do); we can optinally add a MimeType
entry; we can optionally define an Icon; etc.  Due to all the optional
stuff that can go in them, we should simply store the .desktop files in
${FILESDIR} and copy them into place at install time.  (This is what the file does, as described above.)

However, the more I think about it, the more useless I see the file.  The reason is that ~95% of the packages wanting to
install .desktop files, if not all, will simply do:

USE_DIRS+=	xdg-1.1

	${INSTALL_DATA} ${FILESDIR}/file.desktop \

There is usually no need to preprocess the files with SED, because
all the existing ones do not even use hardcoded paths to installed
files.  For binaries, we might want to use full paths, but then we'd
have to go and fix other .desktop files for consistency.  For icons
it's even unacceptable to use absolute paths to them because they
should be themeable.

So I'd rather install the files by hand than with some obscure
variables that mostly do the same.

Even though, there is an issue that bothers me a bit, and is WRT the
MimeType entries.  ATM, if a .desktop file includes a MimeType line,
the package has to include desktop-file-utils/, which
automatically takes care to run update-desktop-database at (de)install
time to properly update the mime database living in share/applications
(and adds such tool as a dependency).

So, consider vim-gtk2.  I've created a desktop file for it with a
MimeType entry in it, which means that it'll have to depend on
desktop-file-utils.  I know that people will be against this (even
though the tool is rather small).

Therefore, I will rework in such a way that the packages
only update the mime database iff desktop-file-utils is installed
(similar to what I did in pkg_alternatives), and then make GNOME
(nautilus, or whatever) explicitly depend on this tool to delay the
dependency as much as possible.

Does this sound ok to you?  Please raise your concerns _now_, not
_after_ stuff gets commited.


PS: I've attached the gvim.desktop file I'm using ATM as an example.

Julio M. Merino Vidal <>
The NetBSD Project -

Content-Disposition: attachment; filename=gvim.desktop
Content-Type: application/x-desktop; name=gvim.desktop
Content-Transfer-Encoding: 8bit

# $NetBSD$

[Desktop Entry]
Name=VIM text editor
Name[ca]=Editor de texts VIM
Name[en_CA]=VIM text editor
Name[en_GB]=VIM text editor
Name[es]=Editor de textos VIM
Comment=Edit text files using a Vi-like interface
Comment[ca]=Edita fitxers de text usant una interfĂ­cie d'estil Vi
Comment[en_CA]=Edit text files using a Vi-like interface
Comment[en_GB]=Edit text files using a Vi-like interface
Comment[es]=Edita archivos de texto usando una interfaz de tipo Vi
Exec=gvim %U