Auto-activation of desktop-specific programs

[Havoc Pennington]

Thiago Macieira wrote:
> I needed some comments on this proposal...
>

Sorry, my thoughts at the time were "sounds hard, I will think about it 
later" ;-)

>> 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
>> too.
>>
>> 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.

Havoc