[Glade-devel] Glade-3/libglade non-widgets RFC

[Tristan Van Berkom <tristan van berkom gmail com> (Tristan Van Berkom)]

I am about to start coding non-widget support in glade-3.

   For those who are confused about non-widgets, non-widgets are all GObject
derivative types that are in some way widget delagetes and pertain somehow
to the UI.

Some examples of these are:
    - GtkSizeGroup
    - GtkTreeViewColumn
    - GtkEntryCompletion
    - GtkAdjustment
    - GnomeCanvasItem

This is the basic design I'm thinking will work:

    o GladeWidget[Class] will now be GladeObject[Class]
      
      This is just a clarification, the entire implementation from
here on out is
      GObject based and not GtkWidget based (ofcourse some extra
functionality will
      be provided for GtkWidget derivitives, such as painting
selections on them etc).

    o Every GladeObjectClass is allowed to act as a "container"

      A GladeObjectClass that acts as a container will have a list of
GladeChildInfo
      records that will contain information such as:
      
      - GType of this supported child type
      - add_child function for this child type
      - boolean representing whether there can be more than one child
        of this type or not.
      - boolean representing whether this child is to actualy be built or if it
        is just a reference.
      - ... anything else ?

      Note that the "supported type" should include all derived types, so
      GtkContainer essentialy supports type GtkWidget as a child etc.
      Children of the GtkContainerClass will inherit this behaviour and possibly
      override it.

    o Object type properties will be handled as children.

      I just dont see an easier way around this problem, if object
type properties are
      dubbed "child objects", they can be selected in the editor
through the same
      pipelines as actual children; the same goes for libglade, custom
"add-child"
      methods can easily be implemented which create an object with 
      glade_xml_build_object() on the child node and proceed by
calling g_object_set()

    o Some child types will only be "references" and will not be "owned"
      by the parenting object.

      An example of this is GtkEntryCompletion, The GtkEntry, would
support a child
      of type GtkEntryCompletion and GtkEntryCompletion would support
a child of type
      GtkTreeModel (Note that "parenting" isn't quite the word, in
glade we consider
      it a parent / child relationship strictly for practical reasons).

      This I think is going to be pretty tough, first question that
comes to mind is
      "how am I going to add a child through the glade ui which is
just a reference to
       another object in the ui ?"

      I think that as far as xml files and libglade goes, this can be
accomplished
      with little effort:
          - Every Object needs to have a "name"
          - Nested in the <child> tag we can do something like:
            <child>
                <reference name="object_name"/>
                <packing>
                    <property ... so and so>
                </packing>
            </child>
          - Adding the actual "referenced" children the the parenting
objects can
            be completely deffered to after the parsing process, to
ensure that the
            referred to object actualy exists come parenting time.

Well; that pretty much wraps up todays brain-storm,
please send back your comments/sugestions.

Cheers,
                                                                     -Tristan