Re: GtkBuilder Public API - Last call

[Johan Dahlin <johan gnome org>]

Tristan Van Berkom wrote:
> Good morning folks,

Thanks for the comments!

> 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.

To me this is outside of the scope of the current builder, but not
impossible to support in the future.

I'd like GtkBuilder primarily support what libglade does but also support
newer features such as treeview, ui mananger and non-widget properties
in general.

> 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)

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.

>    - 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).

>    - 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.

> 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.

> 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.

Johan