Re: application class thoughts
- From: John Ralls <jralls ceridwen us>
- 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, 5 Apr 2010 09:45:51 -0700
On Apr 5, 2010, at 8:36 AM, Colin Walters wrote:
> I forgot to mention - I'd like to experiment with patching at least a
> few applications this cycle, but not trying to change the world yet.
> The standard approach for this is "eggapp", though that has the
> tradeoff that patching non-C apps is a pain in the butt if they don't
> already ship a C shared library (introspection makes this less painful
> but still). Having a GTK+ branch and having OS vendors ship that
> seems like an interesting alternative here.
I think an application class is a good idea*, and much of the Gtk+Application proposal makes good sense. I do think that it's important to keep in mind, though, that Glib and Gtk+ are supposed to be portable and to abstract low-level interfaces, not to enforce them. I saw far too much about session busses and Gnome desktops in your first post. Session busses are a dbus, and therefore Linux, construct; MSWin and OSX have their own IPC and event mechanisms, and Glib should provide an abstracted interface to all three. There are many Gtk+ applications which don't use Gnome and it compromises their portability to insert Gnome desktop features into Glib/Gtk+.
It might be necessary to have two classes, a GApplication class as proposed at http://live.gnome.org/GTK%2B/ApplicationClass which could provide the event loop, termination, and some other standard services and a derived GtkApplication class that provides graphical services (new window, about, window-independent menus, cut/copy/paste, etc.). Both classes should have some way to register new services. (Normally one would just derive a new subclass to provide the service, but writing GObject classes is sufficiently painful that many developers avoid it, so a different approach is called for.)
* Paul Davis wrote for Ardour, and I'm now generalizing for Gtk-OSX, a new Cocoa Mac integration package which centers on a GtkApplication class to mediate Cocoa's NSApplication for Gtk+.
] [Thread Prev