Moving libglade to GTK+

See Also LibgladeWithGobjects

This page is for planning out the move of libglade into GTK+. The following features are planned for the GTK+-2.8 release:

• Backwards compatability with existing .glade files

• Feature parity with current libglade API

• Support for building GtkUIManager based interfaces

• Support for non GtkWidget types, such as GtkSizeGroup, GtkTreeModels, and GnomeCanvasItems

• Add more features here...

The following features are planned for post GTK+-2.8. We want to make sure we can add them, but may not implement them at this time:

• Support for row data in GtkTreeModels

Libglade Custom Handlers and Extension Modules

Outside the core of libglade, there is a fair bit of code designed to allow libglade to help libglade inspect widgets, and patch over missing GObject properties. This code is either inside libglade itself, or in extension modules provided by other libraries.

• libglade/glade/glade-gtk.c

• libgnomeui/glade/glade-gnome.c

• libgnomecanvas/glade/glade-canvas.c

• libbonoboui/glade/glade-bonobo.c

• gnome-media/profiles/glade/gnome-media-profiles-glade.c

The extension modules do the following:

• make sure that all the widgets' GTypes are registered.

• override the function used to construct a particular widget. By default, g_object_newv() is used to construct the widget.

• override the function used to build the children for a particular widget.

• provide a way to find "internal children" of a composite widget by name (eg. the vbox child of a GtkDialog, so you can add children to it).

• override the handling of a particular property for a class (this property need not exist at the GObject level).

Ideally, I'd like to get rid of the concept of libglade extension modules, so we'd need to find some place to put this code. If libglade functionality is part of GTK, then it seems sensible to add it directly to the widgets themselves.

• For custom property handlers:
  • We can add the following new properties (these are in cvs HEAD now, and will be in GTK+ 2.8):

    • GtkRadioMenuItem:group (just like GtkRadioButton:group)

    • GtkRuler:metric

    • GtkToggleToolButton:active

    • GtkToolbar:tooltips

  • We can throw out a few existing special cases:

    • GtkEntry:invisible_char only needs special treatment because glade_xml_set_value_from_string() doesn't have a case for G_TYPE_UNICHAR

    • GtkStatusbar:has_resize_grip became a property in gtk+ 2.4

    • gtk_check_menu_item_set_show_toggle is a no-op

  • Some still need special handling:

    • GtkWidget:visible -- need to be careful about when you set this on toplevel windows

    • GtkWidget:has_default / GtkWidget:has_focus -- can't set these until the widget has a toplevel window

    • GtkWidget:tooltip -- not a real property. Could it be?

    • GtkTextView:text -- not a real property (it's actually on the textview's GtkTextBuffer). Could it be?

    • GtkCalendar:display_options -- redundant with the other real GtkCalendar properties. Do we care?

    • GtkMenuItem:label/use_underline/use_stock

    • GtkComboBox:items

    • GtkToolButton:icon

    • GtkButton:response_id -- this one is really weird

  • The remaining property handlers in glade-gtk.c are for deprecated widgets. Do we actually need to deal with those?
  • (The above only covers glade-gtk.c)

• For the "new" and "build_children" handlers, perhaps have an extra interface that a widget can implement that . The current default handler could be attached to GtkContainer. (non-standard "build_children" handlers would be required for non-containers that have child objects. See LibgladeWithGobjects).

• For discovering the available widgets and finding internal children of composite widgets, hopefully the introspection framework will provide the necessary information.

  • DanWinship: the introspection framework is pretty heavyweight. I think it would make more sense to add API for this: GtkContainer could define an "internal_child_name" child property, or gtk_container_get_internal_child_by_name, or something.

    • JamesHenstridge: what you've described is what I was suggesting. Note that when I talk of the introspection framework, I'm including existing GTK functionality such as property introspection (which libglade does use) -- I wasn't necessarily referring to using the metadata blobs.

Perhaps overriding the "new" function could be removed entirely, if all widgets can be constructed from properties ...

Stuff in Libglade That Could Be Killed

• the GladeXMLClass->lookup_type vfunc. This was added for the benefit of gtkmm, so that it could map from the standard GTK class names to the derived gtkmm classes instead. I've always considered this a bit of a hack, and if gtkmm can do something better, I'd like to see it go.

• glade_set_custom_handler() and "custom widgets". Glade has the facility to add a "custom widget" to a user interface. The properties on a "custom widget" are the C function to run to create the widget plus a few arguments to pass to that function. glade_set_custom_handler() is there for language bindings to override this behaviour (it is global rather than per-GladeXML object, since the custom widgets are built during construction). If we assume that glade will have some way to find out about new widgets (eg. via the introspection API's metadata blobs), then this ugly feature could go completely.

Libglade's Future

Even if this functionality does get added to GTK, the libglade API will have to remain at least until 3.0. If full compatibility is preserved, libglade could be converted to a wrapper around the GTK functionality. If the GTK version is not fully compatible, libglade could remain as it is now, but be considered a deprecated API.

The first option would impose all the legacy requirements of libglade onto GTK, but would mean that everyone is using the same code. The second option would give GTK more room to improve, since it wouldn't need full backward compatibility (eg. handling pre-2.4 GtkToolbars in glade files).