Auto-activation of desktop-specific programs

[Thiago Macieira]

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

Sure.

- X11 starts
- The desktop script is run (by startx or the DM)
- The desktop script ensures that D-Bus is running
- The desktop script starts the desktop-specific daemons
- One of those daemons is the activation manager, which:
  * acquires the org.freedesktop.DBus.ActivationManager name
  * calls ResetActivatableServices
  * reads the user settings from the desktop-specific config files
  * calls AddActivatableService on the D-Bus daemon, according to user 
preferences
- The desktop script continues, ensuring that no user applications are 
launched before the configuration is finished

If by any chance the user decides to switch desktops inside the X11 
session, without restarting the D-Bus daemon, the call to 
ResetActivatableServices will make sure that the other desktop's config 
won't show up.

So, what happens if the user is using a desktop that doesn't have D-Bus 
services? Well, there won't be an activation manager, so the .service 
files defaults may be used. For instance, org.freedesktop.Browser could 
be set to exec the /usr/bin/www-browser script.

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

I'd say that they are expected to change only those few services that 
freedesktop.org decides are desktop-specific services. The first ones I 
can think of are the web browser and the mail client. Obviously, 
freedesktop.org also has to define an object path and an interface to 
which the calls will be placed.

Then the programs themselves have to be modified. A browser like Firefox 
shares the process instance, so it's easy for it to implement the name. 
Whereas Konqueror, which has multiple instances, would have to decide 
whether to elect one instance to have the name or if a helper process 
will be used.

-- 
  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/20070202/f320488d/attachment.pgp