RFC: Application icons/desktop files and their respective tools and specifications

[Simon McVittie]

On Sun, 14 Jun 2020 at 03:14:26 +0300, IFo Hancroft wrote:
> 1. The Desktop Entry Specifications says the name of a .desktop file
> should use be a valid D-Bus well-known name, and follow the reverse DNS
> convention for the for the author and dot and then CamelCase.

(Note that this is a recommendation, not a hard requirement.)

> Then why do the xdg-desktop-menu, xdg-desktop-icon tools search for the
> vendor in the form of 'vendor'-'applicationname'.desktop?

The simple answer is that they were not written at the same time as the
latest version of the specification, by the same people, or with the same
focus.

The "vendor" concept is how namespacing was done in old versions of
the specification. I think the idea was that software installed by
your OS distribution would be installed into /usr and not necessarily
have a vendor (for example fileviewer.desktop), but software installed
from third-party sources ("independent software vendors" or "ISVs")
would be installed into /opt and always have a vendor (for example
microsoft-fileviewer.desktop or rpmfusion-fileviewer.desktop).

The reversed-DNS-name convention makes a vendor prefix somewhat
unnecessary: the vendor can use their DNS name, reversed, as a namespace,
and that will result in their application not clashing with similarly-named
applications from the operating system.

You'll notice that I haven't said anything about community-maintained
apps or installing from source code, which seems jarring when talking
about an open source platform, but I'm doing that deliberately to make
a point - the design with a vendor prefix implicitly assumes that you
can draw a line between "the operating system" and "third-party stuff",
with the desktop environment coming from the operating system, and
"third-party stuff" coming from an ISV. In this view of the world, if a
sysadmin installs community-maintained apps from source code, they need
to choose whether they are treating the app as though it came from an
ISV or whether they are integrating it into their OS. It's one or the
other, and those two are the only options.

xdg-desktop-menu and xdg-desktop-icon seem to have been primarily designed
to be used by ISVs' third-party software, which needs to be somewhat
desktop-independent (so it works on GNOME or KDE or XFCE or whatever)
and ideally also OS-independent (see also the "LSB" ABI definitions,
which basically nobody uses, but they used to be what ISVs were asked
to target) - so the amount of desktop- or OS-specific stuff that these
third-party packages can depend on is extremely limited. If you think
about those tools as primarily being run by something your OS distribution
is unwilling to package or even can't legally package - Adobe Acrobat
Reader, Quake III Arena, something like that - rather than being run by
OBS or LibreOffice, you'll be on the right lines.

You'll notice my example apps are rather old, and the world has moved on
since then. We now try not to install third-party desktop applications
from a .rpm, .deb or "sudo ./installer.run", because we now have things
like Flatpak, Snap and AppImage as better ways to integrate third-party
software in a way that won't conflict with parts of the OS. Similarly, we
no longer encourage ISVs to target the LSB ABIs, partly because Flatpak
runtimes, Snap bases and AppImage bundled libraries do a better job,
and partly because the LSB ABI is so limited that instead, vendors target
some sufficiently old distro version, usually an old Red Hat or Ubuntu,
and use static linking or LD_LIBRARY_PATH to make their own ad-hoc
platform on top of that (Valve's Steam Runtime, based on Ubuntu 12.04,
is a particularly complete example of this).

For modern open-source application software, I would recommend:

* Make it easy for OS vendors and advanced users (sysadmins customizing
  their OS) to package your software as part of their OS: use a common
  build system like Autotools, Meson or CMake, use the standard GNU-style
  installation paths, and install your .desktop files in ${datadir}.

* If you want to distribute prebuilt binaries to make life easier for
  users whose OS doesn't include your project, do that via Flatpak, Snap,
  and/or AppImage (perhaps more than of those).

* Encourage your contributors to do their development-mode installations
  either in one of the above ways, or into /usr/local, or into ~/.local.

I know GNOME has had a lot of success with encouraging new contributors
to use flatpak-builder or the GNOME Builder IDE's Flatpak integration
to build their modified versions of apps in a Flatpak SDK and install
it as a Flatpak app. I'm more familiar with GNOME and Flatpak than with
the others that I mentioned, so I don't know whether Snap and AppImage
have anything similar.

> When using any of the mentioned tools, to install a file (.desktop for
> the xdg-desktop-menu or xdg-desktop-icon, a .png or .svg for
> xdg-icon-resource, etc) do the applications do more than find the
> correct folder on the system and put the file there (I mean besides
> validating the name format)?

If you are behaving like the concept of ISVs that was used in these
tools' design, the answer is "you don't and shouldn't know, it's an
implementation detail of the tools and may change at any time".

If you are behaving like part of the open source community, their source
code will tell you exactly what they do.

    smcv