For the past couple of months I’ve been working on getting KDE applications into the binary bundle format snap.
With the release of snapd 2.20 last month it gained a much-needed feature to enable easy bundling of applications that register a DBus service name. The all new dbus interface makes this super easy.
Being able to easily register a DBus service matters a great deal because an extraordinary amount of KDE’s applications are doing just that. The use cases range from actual inter-process communication to spin-offs from this functionality, such as single-instance behavior and clean application termination via the kquitapp command-line utility.
There’s barely any application that gets by without also claiming its own space on the session bus, so it is a good thing that enabling this is now super easy when building snap bundles.
One simply adds a suitable slot to the snapcraft.yaml and that’s it:
slots:
session-dbus-interface:
interface: dbus
name: org.kde.kmplot
bus: session
An obvious caveat is that the application needs to claim a well-known name on the bus. For most of KDE’s applications this will happen automatically as the KDBusAddons framework will claim the correct name assuming the QCoreApplication properties were set with the relevant data to deduce the organization+app reverse-domain-name.
As an additional bonus, in KDE we tend to codify the used service name in the desktop files via the X-DBUS-ServiceName entry already. When writing a snapcraft.yaml it is easy to figure out if DBus should be used and what the service name is by simply checking the desktop file.
The introduction of this feature moves a really big roadblock out of the way for enabling KDE’s applications to be easily snapped and published.
💺 Blog 