Generalization of the GtkBuilder idea to arbitrary graphs of GObjects

[Dimitri <mitya mageia org>]

Hi,

I am working on a multimedia-related project that will use
GLib/GObject/GTK+/GStreamer/Clutter technologies extensively. The
project will feature a number of externalized (not hardcoded) GUI
fragments as well as a number of external GStreamer pipeline
definitions. Most likely GTK+ will be used only for prototyping (if at
all), and the production code will use Mx or even custom Clutter-based
widget toolkit.

Thinking over the externalization mechanism, I've figured out that 1)
since 1.0, GStreamer doesn't use XML pipeline representation anymore
("it was broken and never worked"), and 2) GtkBuilder won't help me
much, because it is limited to GtkBuildable classes and isn't extensible
enough. That's why I've come up with the idea of having more generic
(de)serialization framework that could be extrapolated to arbitrary
graphs of GObjects. It's also good to have single unified technology for
dealing with both GUIs and GStreamer pipelines. With this, GUI controls
and GStreamer elements could be addressed using unified mechanism. That
would facilitate, for example, defining in a declarative way bindings
for properties of GUI controls and Gst elements.

What's similar between GTK+ and Mx GUIs and GStreamer pipelines:
* they are all composed of GObjects;
* GObjects have properties that could be either primitive or refer to
another GObject (association link);
* GObjects can emit signals that could be connected to handlers (this or
other GObjects' methods).

What's different:
* Instantiation strategy:
 - GTK+ and Mx objects are instantiated via simple construction;
 - GStreamer elements should be instantiated via factory call;
* Implementation of child/parent relationship:
 - GTK+ uses GtkContainer semantics;
 - GStreamer uses GstBin;
 - Mx uses MxBin;
* Other specific features:
 - GStreamer elements' pads could be connected.

Seems like the first part (dealing with generic GObject graphs) could be
implemented in the framework core, while specific features (support for
GTK+, Mx, GStreamer etc.) could be moved into plugins. As for
externalization format, it should be human/machine
readable/editable/writable (some sort of visual composer is planned).
Here, XML seems to be a good choice due to (among other benefits) its
extensibility via namespaces mechanism. Imagine the following code:

<object class="Gtk.Window">
 <property name="title">Foo</property>
 <gtk:child>
  <object class="Gtk.Button">...</object>
 </gtk:child>
</object>

Or:

<object gst:element="bin">
 <gst:child>
  <object gst:element="alsasrc" id="foo">
 </gst:child>
 <gst:child>
  <object gst:element="alsasink" id="bar">
 </gst:child>
 <gst:link src="foo.src" sink="bar.sink"/>
</object>

Thus, the root namespace (elements without prefix) should be handled by
the core, while other namespaces (prefixed elements) will be handled by
corresponding plugins. Support for St (GNOME Shell Toolkit) could be
added as well, giving the ability for shell extension developers to use
declarative UI technology. As far as I know, at the moment shell
extensions have to define their UIs in JavaScript in an imperative way.

I'll appreciate any considerations on this.

Thanks!
Dimitri