Re: Some introspection on GtkContainer children.

[Dan Winship <danw novell com>]

Damon Chaplin wrote:
> Composite children can be marked when created by the container calling
> gtk_widget_push_composite_child()/gtk_widget_pop_composite_child().

Unfortunately, the way it works is sort of broken, because eg, if a 
GtkDialog does:

    gtk_widget_push_composite_child ();
    button = gtk_button_new_from_stock (GTK_STOCK_OK);
    gtk_widget_pop_composite_child ();

then the GtkButton's label and icon will also be marked as being 
composite children, even though GtkButton didn't want them to be (though 
it probably should have wanted them to be, but that's a separate problem).

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

My thoughts on some things that could be done to fix this:

    1. Deprecate all the composite-child-related methods/flags, because
       they can't be fixed without breaking API.

    2. Add a new GtkContainer child property indicating whether a child
       widget is:
        A. "Normal", meaning that the user explicitly added it via
           gtk_container_add() or the like, and that the user could also
           remove (or at least replace) it if they chose.
        B. "Structural", meaning that it's part of the internal
           structure of the parent, and you shouldn't frob it
           directly, but it might have "Normal" children, so it needs to
           be included in the glade file. (Eg, a GtkDialog's vbox.)
        C. "Other" (Um.. "Implicit"? "Emergent"?), meaning that the
           child was *implicitly* requested by the caller and reflects
           the state of some property on the parent, and shouldn't be
           modified directly, and doesn't need to be included in the
           glade file, because its state is completely determined by the
           parent. (Eg, a GtkMessageDialog's buttons, or a GtkButton's
           label).

       Maybe this shouldn't be a child property per se, but should be
       exposed in some other way. In particular, we might want to say
       that only "Normal" children have child properties at all, and
       that the results of trying to get or set child properties on
       "Structural" or "Other" children are undefined

    3. Deprecate gtk_container_foreach(), since there's not much
       consistency in how widgets currently distinguish it from
       forall(), and we can't make them consistent without breaking
       existing apps. Add a new replacement for it that wraps
       forall() but filters the result according to a bitmask of the
       child types above.

    4. Make glade's concept of "internal-name" be explicit, either as a
       new GtkContainer child property, or by the parent using
       gtk_widget_set_name(). Require all "Structural" children to
       have an internal name.

    5. Have some way for container subtypes to indicate that they
       shouldn't actually be treated like containers, for things like
       GtkFileChooserButton (which is a subclass of GtkHBox, but
       shouldn't be treated as such). One possibility would be
       gtk_container_get_max_children(), which could return -1 (no
       limit), 0 (GtkFileChooserButton, etc), 1 (GtkBin and subclasses),
       2 (GtkPaned), etc.

-- Dan