D-Bus activation from desktop files

[Ryan Lortie]

hi,

On Mon, Jun 10, 2013, at 11:46, Matthias Klumpp wrote:
> Where can I read about the reasons for implementing this feature?

The basic reason is something like this:

Many applications (particularly in GNOME) are following the pattern
lately that there is only ever one instance of the application running. 
This was done back in the day with things like libunique, but we grew
some more advanced ways of doing this lately (like GApplication).

When the second instance of the application gets started (by running the
executable) then the second instance notices that there is already a
first copy running.  It then sends a D-Bus message to that first
instance saying "please open a new window" (or whatever) and exits.

The idea here is to avoid having to fork()/exec() and fully dynamic-link
this second copy of the process in order to send a D-Bus message and
immediately exit when (most probably) the process doing the launching is
already on D-Bus to begin with and perfectly capable of sending the
message for itself.

This involves installing a D-Bus service file for the application of
course.  In the event that it is not running, it will be D-Bus activated
in order to receive the message.  In the event that it is already
running, it just receives the message.

In GNOME, many apps are actually taking things one step further: they
install two binaries now; one in /usr/bin and one in /usr/libexec.  The
libexec one is the D-Bus service and it is the main guts of the
application.  The one in /usr/bin is just a small 'launcher' executable
that always just sends a D-Bus message and quits.  This is allowing for
some nice possibilities such as starting applications in response to
D-Bus messages other than for reasons of showing their main window. 
Some GNOME apps are using this to implement D-Bus interfaces to respond
to search requests in gnome-shell as an example, but we also have plans
to use this kind of thing from a few other areas:

 - a notification centre type application that can have notifications
 for email/IM
   programs that are no longer running.  When you select a message, it
   can activate
   the program in order to show the specific message

 - activation for push notifications received by the OS over the network
 so that an
   app can do something like sync your mail in the background, then quit

 - activation because of the passage of time (so that we can have
 alarm-clock type
   programs that don't need to be running all the time)

 - activation for handling a host of potential future "intents"
 interfaces that we
   could have (like perhaps a camera app supports an "acquire image"
   intent).


All of this pushes towards applications appearing more as D-Bus services
providing certain interfaces than as binaries that you run.  When you
look at it that way, activating the app in the traditional "run this
app" or "open some files with this app" sense starts to look like just
another API.

This spec is about standardising that API.

I hope that generally sums up the idea behind this.  Thanks for asking
:)

Cheers