Auto-activation of desktop-specific programs

[Thiago Macieira]

Havoc Pennington wrote:
>>> 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.

I believe you've mixed my 2.b and 3 together by suggesting that only the 
application detaining a specific service name can add/remove entries to 
the service activation list.

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

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

Agreed.

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

We could do that. But I think it's not worth it.

Since it's the desktop that is starting up, its own start-up scripts can 
make sure that the registration is complete before the next phase (i.e., 
loading other programs) starts.

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

Hmm... I had thought that we'd have a common set of desktop-dependent 
services, which are standardised by freedesktop.org.

But it does make sense to have desktop-specific services that map to 
different applications. And it would make sense to have D-Bus start those 
applications too. Consequence: the addition of desktop-dependent services 
should be allowed to overwrite the .desktop files.

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

- new method in org.freedesktop.DBus, called:
	ResetActivatableServices()
	This resets the list of activatable services to the default 
configuration. In other words, it undoes the effect of all 
AddActivatableService calls done.

	This operation may reread the .service files found in the search paths, 
so it is not guaranteed to reset to the very same state in which D-Bus 
was before activatable services were added. This is an optional feature.

	Like AddActivatableService, this method can only be called by the 
connection that holds the name org.freedesktop.ActivationManager. 
Activation managers are encouraged to call this method upon receiving the 
org.freedesktop.ActivationManager name, so as to clear any services added 
by previous activation managers.

- maybe add a new method in org.freedesktop.DBus, called:
	AddActivatableServiceList(in aa{ss} services)
	The same as calling AddActivatableService for each element in the 
services array. It's provided for convenience only.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070125/e62379e4/attachment.pgp