Re: gtk_container_new_child (was Re: Wrapping Box Container)

[Tristan Van Berkom <tristanvb openismus com>]

On Wed, 2010-09-01 at 10:59 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > I like this idea alot and as its a trivial patch I might write one
> > up tonight or tomorrow ...
> 
> well, it's trivial except for the need to add some kind of gobject API
> (or you could do it in a somewhat hacky way without that, I think)
> 
> > I can see how that can reduce some lines of code when building
> > UIs directly with code (not GtkBuilder)... although I think it
> > would be best to avoid as it throws property and packing property
> > names into the same namespace (so if ever packing properties and
> > object properties share the same name, this api will be a little
> > ambiguous as to which will be assigned, or one or the other
> > would be prioritized...).
> >
> > Thoughts ?
> 
> I think packing props should "win" (for back compat, among other
> reasons). If there's a collision and you want to set the prop on the
> child, you would need to just avoid this convenience function or set
> the one colliding prop separately, which seems simple enough. I don't
> know that there would be too many collisions in practice especially if
> we thought about that when naming props.
> 
> It COULD be done where you had to do a NULL separator between
> container and child sort of like this:
> 
> new_child(container, "foo", 1, NULL, MY_TYPE_CHILD, "bar", 5, NULL);
> 
> however since it's a convenience API I think "common case convenience"
> might be better than "handles weird corner case of colliding
> properties"
> 
> Another option is to allow prefixes on the prop names,
> 
> new_child(container, MY_TYPE_CHILD, "parent::foo", 1, "child::bar", 2, NULL);
> 
> where the prefix would be optional and only needed in case of ambiguity.
> 
> The new_child version is harder than just add_with_properties()
> supporting child props, because it involves marshaling to object_newv
> or something. (again needing more gobject API at least for max
> efficiency)
> 

Ahh I see I misunderstood your email... as I can see that 
gtk_container_add_with_properties() already exists.

On the other hand... since g_object_new() will never return NULL...
I'm not sure how much this api would be different than simply
invoking these lines of code:

gtk_container_add_with_properties (container,
				   g_object_new (GTK_TYPE_FOO, 
						 "fill", FALSE,
						 NULL),
				   "expand", TRUE,
				   NULL);

Its just about the same amount of typing in C... and already
has no ambiguities regarding properties/child-properties. 

We could also safely make g_object_set() return the input
object for this type of convenience... like g_object_ref() already does.

Allowing this construct:

gtk_container_add_with_properties (container,
                                   g_object_set (child, 
                                                 "fill", FALSE, 
                                                 NULL),
                                   "expand", TRUE,
                                   NULL);

Ofcourse its perfectly valid C code already to type:

gtk_container_add_with_properties (container,
                                   (g_object_set (child, 
                                                 "fill", FALSE, 
                                                  NULL), child),
                                   "expand", TRUE,
                                   NULL);


although not many people are fans of using the comma operator in this
way... personally I think its quite elegant to use in some cases...
for instance: "ptr = (g_free(ptr), NULL);".

Cheers,
     -Tristan