Auto-activation of desktop-specific programs

[Kevin Krammer]

On Wednesday 17 January 2007 00:18, Havoc Pennington 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)
>
> 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.

While I understand that it would be nice to have the bus do the activation, I 
think for the purpose of runtime user configurable assocations a separate 
mechanism would be more appropriate.

Every desktop environment, even those with just a windowmanager+desktop 
application, have at least one process running through the whole session 
lifetime.

This process acquires a known name, e.g. 
org.freedesktop.DBus.DBus.ActivationManager, and offers an interface for 
starting services, like a factory object creating instances.

The disadvantage is that an application has to do another call if the target 
name is not available yet.
The advantages are that it can be implemented closely to a desktop's 
configuration framework, there is no change required on D-Bus itself, it 
could implement activation policies (like starting a new browser for each 
request or just handing over a previously started on, etc)

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

This sounds reasonable as well.

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

IMHO this is too static. This kind of hints work for the application start 
menu (OnlyShowIn and friends) but if this should work for generic application 
activation, it needs allow runtime modifications.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/20070121/07e1e83f/attachment.pgp