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

[Shane Butler]

Hi Tristan,

I guess it is important to know if James has any plans for future
versions of libglade that are along these lines.

BTW, one of other thing that I have wondered is how the glade xml format
could integrate with GtkUIManager XML files? 

Regards, Shane

On Thu, 2004-11-04 at 06:57, Tristan Van Berkom wrote:
> 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
> _______________________________________________
> Glade-devel maillist  -  Glade-devel@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/glade-devel