application class thoughts

[Colin Walters <walters verbum org>]

Hi,

For GNOME 3 to provide the best experience, we need something like
http://live.gnome.org/GTK%2B/ApplicationClass

(Note: I'm really interested in input in particular from Meego or
other freedesktop people who are probably running into similar
restrictions with our application stack)

The most important thing is to implement the application menu,
offering at least global options like Quit, New Window, About.  And we
want to experiment with moving e.g. Copy&Paste in there, which could
get us to the point where basic applications wouldn't need a
per-window menu.

There are a lot of secondary goals, like ensuring app-uniqueness,
improving remote scriptability, better lifecycle support (when & how
to save state), etc., but they're less important I think than the
menu.

>From my perspective then, I think it's right to define the system-app
remoting interface for an application first.  There is some prior art
in this area:

* GApplication as designed on the current wiki page above
  - Quite good, but we need to figure out what the DBus interface is
  - Would like GTK+ to inject some standard actions like Quit
  - Would like to avoid requiring a well-known DBus name and instead
use the .desktop file (apps *must* have a .desktop file anyways now)

* XSMP
  - doesn't allow us to implement menus
  - is designed around the "log in, work, log out" thin client model

* GNOME session: http://live.gnome.org/SessionManagement/GnomeSession
  - is an API potentially usable both for "desktop infrastructure" and
apps, but is mostly used by the former at the moment (as far as I
know)
  - no API for menus currently, though that could be changed

* OSSO: http://maemo.org/api_refs/5.0/5.0-final/libosso/
  - ( Maemo/Meego people please fill me in on this )
  - Apps to define a DBus .service file, but I can't find any references to a
    standard DBus interface here

* "Nautilus actions": http://www.nautilus-actions.org/?q=node/377
  So this is all about menus, which is good because that's what we need.
  The fundamental tradeoff made here is that the menus are defined statically,
  so there's no provision to change them at runtime, and I think in the long
  term we want that ability.  On the other hand, having them in the
.desktop file
  allows the system to show them when the app isn't running, which is
  a useful advantage.  On the other other hand, the actions you'd want to expose
  while an app isn't running seem like they'd often only partially intersect the
  actions you'd have while it is running.

A bit more on nautilus actions.  Let's say you're a note taking app.  You
might want to expose a menu with the 5 most recently used notes, in
addition to Quit and About.  Doing this in the .desktop file isn't possible.

So, let me strawman a bit.  Let's say we had these DBus interfaces:

org.freedesktop.Application
  method Quit()
  method ao GetActions()
  signal ActionsChanged(ao)

Where "ao" is array of object path, each object of which implements:

org.freedesktop.ApplicationAction
  property b Enabled
  method Invoke()

Now the current GApplication spec has actions which take arguments,
which is more oriented towards scripting.  My take is that this should
be a separate interface, or we just say you use GDbus directly.

Also, with this we can avoid requiring a well-known dbus name and say
that for a given app you can find it at the path
"/org/freedesktop/Application" from the unique name.  This means that
you can't (easily) have multiple apps in one process though.  Maybe we
could have a separate API for this case.