Re: GtkBuilder status

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

Hi all,

/me calls mail_thread_join() on this thread...

<quote Matthias Clasen>
Nothing wrong with allowing buildable menus or toolbars, but how do
you propose that they should achieve what uimanager does, mainly
separation of ui and actions, and merging of uis ?
</quote>

   Well, the merging of UI's is not very complex, I would propose that
this be implemented by the toolbar and menubars, objects that implement
the GtkMergableIface would be responsable for merging GtkMergableChildIface
implementors in a mergable heirarcy (the child iface would only be
nescisary to add a "element-name" property in order to compare mergable
children properly, and coincidentally; allow for a 
get_child_by_element_path()
like api)... the merging/unmerging part is simply a matter of keeping track
of which children have been added from which heirarchy.

I'm afraid I'll have to take at least one day to better my knowlage about
exactly how GtkAction works, but from the little I already know and my 
first glances...
I dont see why the menu items cant be prefabricated with actions attached,
and the action groups made available by the GtkMergable implementors
(allowing for seemless integration of get_accel_group() and such).

I will delve a little further into the action code and come up with 
something
a little more solid...

<quote Johan Dahlin>
Yes, these simple cases would be possible to handle somewhat, it would
prevent you from using the delimiter character in object names, which
wouldn't be a too big deal.
However, specifying model data for GtkListStore and GtkTreeStore is not
really possible using properties, unless you want to embed CDATA which
has a defined internal structure. And is that the road we want to go?
</quote>

Good point,
   I see that at some point; a string buffer as xml data will be
insufficient for some data representations, CDATA is not very nice,
and using external resources is clunky and hard to maintain.
Either way; we'd still surely need some versioning mechanism
to allow objects to extend on how they are build and support older
versions of definition files etc... so I suppose it doesnt really make
a difference...
   I do think its important that these extra tags are provided on an
object specific basis and be understood as such, i.e. the <widgets>
thing is really a GtkSizeGroup feature... not a GtkBuilder feature, also;
any third party should be allowed also to implement thier own custom
tags as needed (although I think your implementation already covers this 
need ;-) ).

Maybe integrating a <custom> tag here would be usefull... (not sure)... 
to allow
parsing of "custom" subtrees in the xml in a generic/abstracted fashion
(as long as the builder code doesnt have to have any knowlage of what 
exactly
these custom tags are supposed to be).

<quote Owen Taylor>
There has been a fair bit of quoting without attribution on
this thread, and I don't think Tristan's mail has made it to the
list at all, so I can't really comment.
</quote>

You can read my initial comments here:
http://mail.gnome.org/archives/gtk-devel-list/2006-May/msg00103.html

I sent this mail straight from my gmail account, so maybe it wasnt
forwarded properly...

Cheers,
                                      -Tristan