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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list