DBus service for screenshots.

[Simon McVittie]

On 25/09/15 17:37, Boudhayan Gupta wrote:
> Now that we've retired KSnapshot and are replacing it with a new tool,
> we thought we could improve on invokation by not hardcoding a single
> command (in KHotkeys or in a config file), but use D-Bus activation to
> fire up the application implementing the org.freedesktop.Screenshot
> service.

"The" application?

Using D-Bus service activation for an implementation-neutral name is
problematic. Consider a machine shared between Gordon and Kate, who
prefer GNOME and KDE respectively; as a result, it has both desktop
environments installed. Kate logs in and takes a screenshot, but the
desktop environment does not have an org.freedesktop.Screenshot
implementation already running, and is relying on service activation.
How do you arrange for dbus-daemon to launch the KDE screenshot tool,
and not the GNOME screenshot tool?

In traditional D-Bus, it is technically possible for
/usr/share/dbus-1/services to contain .service files for both the GNOME
and KDE implementations; however, there is no concept of priority, so
dbus-daemon will pick one essentially at random (I think it's either the
first or last in readdir() order).

This is why we recommend that the implementation of the activatable
service com.example.foobar is always a file named exactly
com.example.foobar.service - that way, package managers won't allow a
conflict to exist (or if you're installing from source or your package
manager is awful, you get "last one installed wins" semantics, which are
not ideal but are at least deterministic). Unfortunately, we cannot
*require* that, for backwards compatibility with services that give
their .service files some other name.

In kdbus, which is a little less concerned about backwards
compatibility, I believe the plan is for the conflicting situation to be
considered an error.

This is solvable, for instance by desktop environments arranging to put
a symlink to your preferred implementation in
~/.local/share/dbus-1/services (which is higher priority in the search
path than /usr/share); however, you do have to go to some effort to
solve it.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>