org.gnome.Application DBus Interface

[Alex Jones <alex weej com>]

Hi list

the org.gnome.Application DBus interface provides a way for applications
to expose common application functionality in a standardised way.

The interface XML looks like this (for Rhythmbox, e.g.):

  <interface name="org.gnome.Application">

    <method name="Launch">
      <annotation name="org.freedesktop.DBus.GLib.CSymbol"
value="rb_shell_application_launch"/>
    </method>

    <method name="InvokeURIAction">
      <annotation name="org.freedesktop.DBus.GLib.CSymbol"
value="rb_shell_application_invoke_uri_action"/>
      <arg type="s" name="action" direction="in"/>
      <arg type="s" name="uri" direction="in"/>
    </method>
    
  </interface>

One of the benefits of this, is that the code for communicating with a
running process can be (but doesn't have to be) removed from the main
program. All the program has to do is export this DBus API and grab a
well-known bus name. It needn't even process any command-line arguments,
as any communication with it is done via DBus.

I have written a program to deal with backwards compatibility with the
FDO Desktop Entry "Exec" option, meaning that we don't actually have to
make any changes to Panel or GNOME VFS to start reaping the rewards of
this now. (dbus-send is inadequate, because there needs to be some
simple logic for this purpose to decide whether to call Launch or
InvokeURIAction.) It is currently called gnome-application-exec, and it
works like this:

Exec=gnome-application-exec $service_name $application_path
$default_uri_action %u

For example:

Exec=gnome-application-exec
org.gnome.Rhythmbox /org/gnome/Rhythmbox/Shell Play %u

Or, for the example of the Epiphany Bookmarks "Application" provided by
the Epiphany "Service", that does not handle any files:

Exec=gnome-application-exec
org.gnome.Epiphany /org/gnome/Epiphany/Bookmarks Noop

(The Noop action is a dummy. It will never be used, because there are no
MIME types in the Desktop Entry file for Ephy Bookmarks anyway.)

If a URI is passed in %u, it calls InvokeURIAction with the default
action specified in the command line.

If no URI is passed, it calls Launch.

With a running Rhythmbox...

alex flash:~$ time gnome-application-exec
org.gnome.Rhythmbox /org/gnome/Rhythmbox/Shell Play

real    0m0.120s
user    0m0.036s
sys     0m0.016s

alex flash:~$ time rhythmbox
real    0m0.328s
user    0m0.208s
sys     0m0.028s

As the timings show, gnome-application-exec does a much quicker job of
presenting the application to the user (and it /does/ wait until the
Launch method returns, which in turn waits until the rb_shell_present
method returns -- i.e. it is genuinely faster to do, ultimately, the
same job) You can really feel this responsiveness when you use a panel
launcher, for example.

These timings are representative of the process of opening files, too.

Furthermore, when the launching code (Panel/GNOME VFS) chooses to call
these methods directly from its own DBus connection rather than starting
another process to do it, the speedup will be even greater.

Issues to be worked on:

     1. Startup notification
     2. Multiple screen scenarios
     3. Actions on multiple URIs
     4. GObject API to wrap the DBus API
     5. Distinct file actions

I specifically need some help with figuring out the best way to do
startup-notification and supporting multiple screens right now.

I think this would be a great opportunity to get achieve some
performance gains and to simplify our application code for 2.22. Please
help me continue. :)

Thanks