Change in application desktop file prefix

Alex Merry kde at randomguy3.me.uk
Fri Feb 14 14:50:12 GMT 2014


kdelibs4 strongly encourages (by providing ${ICON_INSTALL_DIR}) its
users to install their application desktop in
$PREFIX/share/applications/kde4/.

In KDEInstallDirs.cmake in extra-cmake-modules (the standard for KDE
applications in a post-kdelibs world), we change this to
$PREFIX/share/applications/.

Rex Dieter has pointed out that the desktop menu spec[0] strongly
encourages the use of desktop file prefixes ("it is recommended that
providers of desktop-files ensure that all desktop-file ids start with a
vendor prefix."), and this is what the "kde4" directory was meant to
achieve (the menu spec says that prefixing file names with foo- and
putting the files in a foo subdirectory are equivalent).

However, while this equivalence may be fine for the desktop menu spec,
my experience is that it causes nothing but trouble in other places
(particularly when dealing with [1]).

The pattern that other desktop environments (such as GNOME and XFCE)
seem to use is to prefix only those desktop files with generic names
(gnome-disks.desktop, xfce-settings-manager.desktop), and these are
filename prefixes (not subdirectories).  Other applications, such as
Thunar and Evolution, have no prefix (Thunar.desktop, evolution.desktop).

Given that applications with clashing desktop file names are almost
certainly going to cause clashing binary names anyway, my view is that
the kde4 directory causes more issues than it solves.  We may still want
to prefix things like system settings, though (like
kde-systemsettings.desktop).  It seems pointless to do the same for
things like Amarok and Okteta, though.

Does anyone (and downstream packagers in particular) foresee issues with
this change?

Alex



[0]: http://standards.freedesktop.org/menu-spec/menu-spec-latest.html
[1]:
http://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry




More information about the kde-core-devel mailing list