Re: application class thoughts

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

John Ralls

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]