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 - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/glade-devel _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
