Auto-activation of desktop-specific programs

[Havoc Pennington]

Hi,

Thiago Macieira wrote:
> 
>> 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)
> 
> I have no idea what you meant by this. We're not talking about adding or 
> removing files. The setting in question is somewhere deep inside the 
> desktop's configuration.
> 
> Unless the desktop decides that such a configuration should be made global 
> (to all desktops). To allow for such cases, I think the desktop-provided 
> services should not be allowed to override the .service files.
> 

The point is, if there's an org.freedesktop.Browser and an app tries to 
use it, then that name should always activate the "preferred browser" 
that I have configured for the desktop (firefox, epiphany, konqueror).

Each desktop will already have a config option for this, but currently 
there is no way to cause that config option to affect what's activated 
for the org.freedesktop.Browser name.

>> 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.
> 
> Proposed API:
> - new method in org.freedesktop.DBus, called:
> 	AddActivatableService(in a{ss} details, [out b success?])
> 	The "details" parameter is a list/map of key-value pairs, just like 
> the .service file format. Therefore, two keys are mandatory:
> 		Names	- the service name to be activatable
> 		Exec	- the full path to the executable to be run
> 	An optional third is defined:
> 		Override	- contains either the word "true" or "false". If "true", 
> override any .service file definitions; if "false", .service files take 
> priority.
> 
> 	The AddActivatableService method can only be called by the connection 
> that currently holds the name org.freedesktop.ActivationManager. 
> Therefore, the application wishing to configure the list of services must 
> first RequestName the org.freedesktop.ActivationManager name and be sure 
> to own it (either through the NameAcquired signal, or through 
> RequestName's reply).

Can you go over how this would be used?

The most important question I think is the policy question; i.e. what 
changes are desktops expected to make to the activatable services.

This was always the problem with the menu spec, I put in that OnlyShowIn 
thing but it just created a whole problem with figuring out when to use 
it, and was sort of a big pain when nobody knew.... it was probably a 
net positive in the end since some cases were relatively clear, but 
still there was mass confusion in some less clear cases.

Havoc