application class thoughts

[Emmanuele Bassi]

hi Colin;

thanks for picking up the ball here. I was about to start working on
this in order to have a GIO patch ready to play with.

On Mon, 2010-04-05 at 11:16 -0400, Colin Walters wrote:
> 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.

yes; the MeeGo Netbook UX goal is actually to get rid of menus
altogether and display the actions, whenever needed, inside a simple
combo-style widget.

> 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.

app-uniqueness is probably higher on that list, since the GNOME Shell is
one of the big consumers of these kind of applications.

> >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

Quit was already planned, along with Raise/Present.

>   - Would like to avoid requiring a well-known DBus name and instead
> use the .desktop file (apps *must* have a .desktop file anyways now)

a bit of back story here: the well-known name is something brought in
from libunique. it served the purpose well, since the well known named
allowed to implement both a D-Bus based IPC and a UDS-based one - though
the UDS-based one is just meant as a stopgap solution until D-Bus over
SSH works properly.

I'm not overly attached to the well-known name; the dot-desktop file is
a good requirement as any, and since everyone should have a dot-desktop
file, it would solve the uniqueness of the name in pretty much the same
way.

> * 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

AFAIR from my time in Maemo-land, there were a set of interfaces to be
implemented, mostly for session/power management; application launching
was done through D-Bus activation, and application menus were managed by
the window manager to be part of the top panel.

> 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.

the reason I defined actions was not entirely for scriptability (though
it was a concern); some actions inherently require arguments, unless you
defer all handling to the application itself - which may or may not fit
in your user experience. for instance, if I want to open a list of URIs
with an application I might have a section of my shell that is already
capable of selecting that list of URIs - hence I should just select the
list of URIs and then pass them to the application through the
OpenURIList() action. I'm not sure this falls under the "scripting"
label; it's more interaction between an application and a shell.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi