Re: GtkBuilder Public API - Last call

[Tristan Van Berkom <tvb gnome org>]

On Wed, 2007-06-13 at 12:13 -0300, Johan Dahlin wrote:
[...]
> Ideally not.
> It seems to me that most of the virtual properties were hacks.
> Preferably the widgets should be fixed upstream instead.
> 
> Yes, there are also special cases such as visibility of windows and
> focus/default. I think they are a different use case from virtual properties
> since they are real, it's just that their behavior changes a little,
> setting these properties are just delayed until the parsing is finished.

Definitly agreed here.

> 
> >    - 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.
> 
> I still have the opinion that the builder shouldn't need to know about
> packing properties, since it's something which is specific to the relation
> of GtkContainer and their children.
> In the same way as attributes are specific to anything implementing cell
> layout and cell renderers.
> 
> Which are the custom packing properties you want to support anyway?
> Seems like me that some of them are handled (expander,frame,notebook),
> some of them not needed (menus, toolbar, layout) and the rest on deprecated
> widgets (clist).

Here's an example, lets say I have an animated widget, the widget
has a State object for every state 
(up/down/insensitive/<insert your flavour here>), every State can
have a number of Animations, there can be an Animation object that
defines the visual aspect of the current state, other Animations
can be added as intro's for when performing transitions from other
animated states (like when your icon goes from "running" to "doing
cartwheels", you need to add the correct transition animation).

I use packing properties to tell State "down" that its Animation 
child is in fact the intro for passing from State "up" (and possibly
another as an intro from State "disabled").

Anyway, my point here is not wrt code that exists already in Gtk+,
I am of the opinion that GContainer iface is "missing", and that
objects in general use other objects in general, and in that process
of ownership, packing properties are an essential thing.

> 
> >    - 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...)
> 
> Something like this would be better, to have an api which would
> define a relation between an <object> and a <children>.
> I don't know how this should be done right now, but it could easily be
> supported in the future without breaking the API, such as adding
> a couple of new vfuncs to the GtkBuildable class.

Ok point taken, the builder is a vast feature with many possibilities,
it would be next to impossible to satisfy everyones demands at once so
the main concern here is compatability and room for improvement.

We can add GContainer iface for introspection of packing properties on
non-GtkContainer objects in the future, and add child_set_property()
vfunc to the buildable as its counterpart - I would really like to
get this aspect "in" sooner than later (and hopefully not forgotton)
but what matters now is to land the friggn builder so we can start
working on it :)

> > 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>
> 
> I mainly kept this for Glade compatibility, I'd be happy to remove the
> object attribute if it's not something you're keen to support.

I think you misunderstand me, my request is that we do support
"objects", and we do support "swapped", just that one does not
imply the other.

in this patch[1] to libglade we added support for optionally looking
up the userdata in the running application using dlsym(), which would
also be a useful alternative for the user_data field, this could
be a good future expansion to how the user data is used in builder
(integers or enums passed in as GINT_TO_POINTER() are also a
good candidate).

So to recap:
  - The user should be allowed to specify something for user_data of
    a signal (currently only "object" is supported)
  - The user should be allowed to connect handlers "swapped" for
    whatever convenient reason (i.e. connecting gtk_widget_hide()
    on some other object and swapping it so that its the first arg).
  - The builder should not assume that if the user specified a
    user_data, that the user_data should become the first argument
    (why ? just because its confusing when the underlying framework
    makes that kind of assumption for you, and because it denies you
    the possibility of using user_data without being swapped).

> 
> > 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).
> 
> I disagree, XUL supports it, why shouldn't GtkBuilder?
> 
> And also, the ID doesn't have to be used by merging, it could be used by any
> other apis which would want to access any state specific to one
> add_from_file/string call.

I'm not saying that the builder shouldnt allow you to create
a mergable/unmergable UI, I just think that this should be done
a little deeper.

You should be able to create a mergable/unmergable UI without
the builder, and the builder should rely on the underlying
framework to support merging of UIs.

Cheers,
                     -Tristan

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