Re: application class thoughts
- From: Emmanuele Bassi <ebassi gmail com>
- To: Colin Walters <walters verbum org>
- Cc: xdg lists freedesktop org, gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: application class thoughts
- Date: Mon, 05 Apr 2010 21:46:21 +0100
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:
> For GNOME 3 to provide the best experience, we need something like
> (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
> 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
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
> * 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.
] [Thread Prev