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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
