In depth support for custom widgets


Currently Glade supports custom widgets by way of letting the user introduce a catalog and optional plugin for their custom widgets, this has been great to allow integration of customized portions of the UI, easing things like integration of a GstVideoSink or MozView widget into your application directly, or integration of GTK+ based toolkits to be run on a kiosk or a hand held device.

After recently being hired to do some work that happened to involve using IDEs I realized that today that just doesnt cut it. Simply put: its not important or a challange anymore to integrate a mozilla or gstreamer widget into the Glade catalog, people want to derive widget classes from thier interface directly and easily, not because they want to use an exotic widget... but just because they can write more encapsulated and reusable code, presumably better code than when using the currently popular technique of connecting to signals and playing god with every single element of the UI from a main application logic object or workspace.


Glade Catalog Updater using GObject Introspection

The Glade catalog describes a set of GObject types that are to be mentioned in the Glade palette, up to date this catalog has always been written by hand and updated by hand - now that we have releases of gobject-introspection; not only do we have the opportunity of automating things like updating targettable versions of newly introduced properties and signals and deprecation data (every GTK+ release I have to go over the list by hand and mark the "deprecated" and "since" data), we also have the possibility of generating usable catalog completely from GIRs with the restriction that we have usable editors for object classes found in the GIR (object classes that do not derive from GtkWidget, can only have thier properties and signals setup but not appear in the workspace currently).

The Catalog updater should respect a simple api such as:

GladeCatalog *glade_catalog_new_from_gir (const gchar *gir_path,
                                          GError     **error);

and also to update catalogs:

void         glade_catalog_update_from_gir (GladeCatalog *catalog,
                                            const gchar *gir_path,
                                            GError     **error);

Then we can either compile a program against the core library or just add command line options to Glade to create new catalogs or update existing catalogs with introspection data.


Now assuming we have the frameworks layed out discussed in the previous section, we can move on to implement fancy features, what we are going to want to add, we could go about it a few ways with a few UIs, this is what I have in mind right now:

  • There will be a clean separation between catalogs loaded at init time by Glade (installed catalogs or catalogs loaded via the GLADE_CATALOG_PATH environment variable).
  • When the user edits a project, every object gets a new attribute in the property editor, the "Implementing Class" field.
  • User Implemented classes will be shown in a special portion of the palette and will be a part of the project data
  • A User Implemented class can also optionally be attributed a gir by the User
  • If a User Implemented class has introspection data available (i.e. it has a valid gir with the "implementing class" name listed and parented by the correct ancestor type); then the user can also edit any added properties or signals that were found for that class in the GIR.


The way GtkBuilder works we should be able to just work around it, although it would be nice to tell GtkBuilder that an "Implemented Class" is assumed to exist and doesnt need to be versioned by any catalog.

Apps/Glade/Roadmap/CustomWidgets (last edited 2013-11-18 19:35:45 by WilliamJonMcCann)