Re: Some introspection on GtkContainer children.

[Tristan Van Berkom <tristan van berkom gmail com>]

> Damon Chaplin wrote:
> They can also be named with gtk_widget_set_composite_name(), though this
> hasn't been used much in GTK+ itself.

And thats a damn shame :(

Right now I think the most evident practicle problems I'm seeing is:
    - Composite children need to be marked as such in order to properly
      implement copy/paste (i.e. recursivly duplicate) composite widgets.

    - Composite children need to be named in order to reference them in
      the glade file to set properties on them without creating them.

At the moment in glade-3; I'm trying to mark all composite children
explicitly; and I know it wont work properly unless *all* composite
children are marked manually, this will turn out to be a nightmare in
the long run for two reasons:
     - For each composite child we'll have to struggle to mark it both
       in libglade & in the builder.
     - The moment that someone enhances a Gtk+ composite widget adding
       a composite child the whole system will break; which leads me to
       ask; Do we need to implement composite children metadata in the
       builder with versioning information ? (i.e. composite child exists
       "Since 2.6") ?

Ofcourse, all of these problems would be completely (or almost completely)
addressed if gtk_widget_set_composite_name() was a requirement for composite
children (then I'd only have versioning information to worry about).

Here's a practicle question; If we were to enforce gtk_widget_set_composite_name()
throughout the Gtk+ code base (I'm sure I could get through it in no time):
When would I see that code in a released version of GTK+ ?

glade-3 is definitly stablizing, if composite widget issues we're out of the
way we'd have custom editors (i.e. menu/toolbar editors) to deal with and a
few minor details (i18n'ness & a11y stuff) before I could envision a serious
beta release.

All that being considered, would it be reasonable to target a Gtk+ version
that has gtk_widget_set_composite_name() enforced ?
(I for one think so... since that wouldnt break compatibility with older
versions of glade files afaics...)

Dan Winship wrote:
> Damon Chaplin wrote:
[...]
> > Ideally a GUI builder shouldn't have to touch composite children - the
> > properties of the widget should be enough to configure it completely.
>
> And we're far from that ideal, because widgets are totally inconsistent 
> about how they treat their internal children.

    Agreed for the most part, but what about adding buttons manually to
a composite child; example is the action_area hbuttonbox of a GtkDialog
& children ?

Maybe ideally a composite widget should have an api for adding children ?
or one could use a "action-widget" child property on the GtkDialog so that
the GtkDialog could hold a reference and implicitly put it in the action area ?
(which wouldn't work since a GtkDialog is a GtkBin...)

> My thoughts on some things that could be done to fix this:
[...]
Agreed for the most part on all of these idealistic comments :)

as specially noted that there are in effect three types of child
widgets; "normal", "added as a result of a property value"; "added
as a composite child which is constantly present".

I think that if we're going to talk of ideal scenarios, GtkContainer
should probably be a GInterface and allow for any object to have child
objects; which also could be composite or not; children also tend to
have different relationships to parents; for example a GtkMenuItem
parented by a GtkMenu isnt exactly a GtkContainer --> GtkWidget relationship,
its also concievable that a parent object can have multiple children
of multiple relationship types.

Cheers,
                                      -Tristan