Auto-activation of desktop-specific programs
hp at redhat.com
Tue Jan 16 15:18:09 PST 2007
Thiago Macieira wrote:
> I needed some comments on this proposal...
Sorry, my thoughts at the time were "sounds hard, I will think about it
>> 2) Put the .service file somewhere else and somehow make that known to
>> dbus-daemon. We have two options:
>> 2.a) Make it known at dbus-launch time. We have the $XDG_DATA_DIRS
>> variable that was introduced into D-Bus's config for this exact purpose.
>> So this option can be used right now. The cons: D-Bus mustn't be started
>> before the actual desktop script is run (for instance, dbus-launch would
>> be run by startkde). Also, modifying $XDG_DATA_DIRS may affect the menus
>> 2.b) Make it known at run-time: we'd add a new method to
>> org.freedesktop.DBus that would add a new path to be searched
>> for .service files. Pros: solves the problem of starting the bus daemon.
>> Cons: can those paths ever be removed? Can any program add them?
>> Imagine the use-case when a program from another desktop accidentally
>> adds its own paths.
I like 2.b fairly well. I think the cons are resolvable and the
implementation would be fairly simple.
We should also consider the case of "setting your preferred browser" or
whatever, where if the desktop knows your preferred browser it should
set it up to implement org.freedesktop.Browser or something. To do this,
perhaps in addition to adding/removing a .service directory, it could be
possible to specify a specific .service file by name or to specify that
for org.freedesktop.Browser, prefer a .service file that also offers
org.mozilla.Firefox (assumes Names= support I guess)
In general I would think of this like the "xsettings manager" where
there is some appointed application that has the ability to change the
activation settings. A simple way to do this is to add a policy to
session.conf saying you have to own
org.freedesktop.DBus.ActivationManager in order to call these methods,
or something like that.
There would be some race condition problems on login, if the .service
file path or priorities were not modified early enough in the login
process. This seems possible to fix though by having login block until
the "activation manager" finishes its configuration of the bus.
Another analogy to the "xsettings manager" is that the setting would
really be stored in a desktop-specific way (e.g. gconf) and the manager
reads and forwards that setting.
Hmm, thinking about it a bit more, adding/removing a .service directory
is a little worrisome; what we want to do here is prioritize what app
will handle a generic bus name, but if we're not careful we could also
make it so org.gnome.GEdit simply did not exist under KDE (for example).
So perhaps only reordering the .service file directories should be
allowed, or some kind of Environment=KDE field should be allowed in the
.service file and the method on the bus would let you set a list of
environments in priority order.
Obviously these are all half-baked thoughts, I don't know exactly how it
would all work out.
More information about the dbus