Auto-activation of desktop-specific programs
thiago at kde.org
Thu Dec 28 05:28:32 PST 2006
The discussion on the xdg mailing list has come to the point of asking:
how does one application talk to a desktop-specific program via D-Bus?
The example in case is the help-viewer program, a hypothetical
The use-case is simple: this arbitrary application is running and wants to
display a help page. It should suffice to make a call into the
org.freedesktop.Help service with the appropriate object paths and
interface, calling for a certain file to be displayed. The exact details
of such call, the format of help files, etc. are all beyond the scope the
problem at hand.
The problem at hand is simple: how does the desktop associate its own help
program to the org.freedesktop.Help well-known service name?
There are only two main possibilities:
1) the desktop acquires such a name at startup
or 2) the program is started when needed
In option #1, it means we either have the program running and taking up
resources (a complete waste), or we have a proxy program holding the
name. Both options are, IMHO, ugly. We can do better.
For option #2, starting it when needed, we have to ask the question: how
does the system know which executable to run? Remember that this is a
1) Put the .service file in /usr/share/dbus-1/services, with an Exec= that
is a wrapper program. When that wrapper is run, it detects which desktop
environment is running and exec()s the actual target program.
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
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.
3) Delegate the starting to a running, helper application. This helper
application would acquire a well-known service name and would provide the
daemon with a list of auto-startable service names. It would also have
one method call that means "start this service name".
Pros: flexible enough to accommodate each desktop's own configuration,
allows for run-time updating of the list of services startable according
to each desktop's policies, allows even for run-time changing of the
desktop, mechanism as well as future needs
Cons: much more complex to implement
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061228/867dff55/attachment.pgp
More information about the dbus