Re: GtkBuilder Public API - Last call

[Tristan Van Berkom <tvb gnome org>]

Good morning folks,

What I really want to discuss in this thread is properties, packing
properties and also more specifically, packing properties on
non-GtkContainer GObjects - I use a custom gtk+ based toolkit that
makes heavy use of delagate GObjects in the widget hierarchy
(objects that define how a widget behaves when in a certain "state",
objects that animate widget->window etc etc), I've found that in
an object heirarchy, as soon as one object "owns" one or more
other objects; packing properties are an essential thing.

So these are the points I want to raise specifically:
   - Do we want support for virtual properties ?
     (properties handled by the GtkBuildable instance but are
     not handled on the object and have no GParamSpec), examples
     of use cases are the exceptions coded into libglade's glade-gtk.c

     Ideally I think we dont need to support them, but they could
     turn out handy so I'm just pointing it out. (note that I
     implemented this as creating them by GParamSpecString properties
     in my patch suite[1], so it doesnt represent alot of work)

   - GtkBuilder still doesnt handle packing properties, GtkContainer
     treats them like a special case, making it difficult for child
     gtkcontainers to do anything for buildable->child_set_property()
     and chain up to its parent implementation (i.e. lots of voodoo
     has to be done to parse them manually using the custom_start/end
     stuff, also leaving it unclear if chaining up is even possible
     here).

     Again, I already did this work in my patch suite so it doesnt
     represent alot of work (I can refit individual patches against
     Johans work for this if so desired)

     I really consider packing properties essential and I really hope
     that the builder will recognize them as something more than just 
     an anomaly of GtkContainerClass.

   - One step further - For the time being we dont have a GContainer
     iface, so packing properties on non-GtkContainer objects cannot
     be introspected, for this I request that packing properties be
     passed along as GParamSpecString properties (like I did with
     virtual properties), so that non-GtkContainer GObjects dont have
     to write custom parser voodoo just to support packing properties.
     (This ofcourse is redundantly also available in the work I did
     for GtkBuilder, and ofcourse I can port it in...)


Another important point that was raised:

On Wed, 2007-06-13 at 10:01 -0300, Johan Dahlin wrote:
[...]
> Well, actually swapped handlers are supported, using the object attribute, eg:
> 
>   <object class="GtkButton" id="button"/>
>   <object class="GtkEntry" id="entry">
>     <signal name="activate" handler="button_clicked" object="button"/>
>   </object>

I think its quite important here to not repeat one of the 
the most obvious mistakes of glade/libglade, swapping the
signal based on the fact that an "object" was specified
is confusing - it also rules out the use case of specifying
a signal that is not swapped & has an object user_data.

Can we please not swap signal handlers unless they are
explicitly specified ?

  <object class="GtkEntry" id="entry">
    <signal name="activate" handler="button_clicked" object="button"/> 
  </object>

On Wed, 2007-06-13 at 10:01 -0300, Johan Dahlin wrote:
> GtkBuilder is currently not supporting unmerging/merging of
> interfaces,
> but it might do in the future. I changed the api to return an integer
> instead of a boolean to be able to support that feature without
> adding a new API.

I think this is a little offtopic but since it was raised here's
my opinion; I think that merging/unmerging shouldnt be tied into
the builder, some containers could implement GtkMergable, even
GtkContainer could provide a default implementation (menus might
get treated differently etc).


Cheers,
                  -Tristan


[1]http://bugzilla.gnome.org/show_bug.cgi?id=383035