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/> _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
