Re: gtk_container_new_child (was Re: Wrapping Box Container)

[Havoc Pennington <hp pobox com>]

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)

Havoc