Re: Generalization of the GtkBuilder idea to arbitrary graphs of GObjects

[Tristan Van Berkom <tvb gnome org>]

On Thu, Dec 13, 2012 at 4:52 PM, Dimitri <mitya mageia org> wrote:
> 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.
>

Hi,
   I don't have time for a full-fledged response but a couple of points
I'll write down in passing.

First, yes most of us agree that GtkBuilder/GtkBuildable should have
went down into GObject (actually the fact that we could transparently
put them in GObject later, was a reason why this was not a blocker
for Johan to originally land the GtkBuilder patches years ago), it
just never happened.

I've also had the idea to use it with GStreamer, however after
a brief conversation with people on #gstreamer it became clear
to me that building pipelines from xml was broken by design.

GStreamer has evolved into something much more dynamic and
should generally not be defined in the strict confines of xml
(i.e. dynamic caps negotiation etc make it possible to resolve
an undefined pipeline by examining the data which runs through it).

However, perhaps a less strict xml definition could be of benefit,
I'm not sure if there is much middle ground to be reached there.

In any case, thanks for bringing up discussion on this, it would
be nice indeed to have something more unified for deserialization
of GObjects.

Best Regards,
         -Tristan


> 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
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list