Re: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Owen Taylor <otaylor redhat com>]

[ Apologies if this stuff has been covered further down in
  the thread, I'm reading and replying in order...]

Tim Janik <timj@gtk.org> writes:

> as i stated earlier, i think that is too much of a hurdle, for being
> implemented consistently. i'd rather like to have a generic mechanism
> implemented that attempts to give composite widgets a generic name,
> i.e. consisting of the widgets type, plus it's position within the
> parents child lists upon creation (can be queried through the child
> arg ::position(widget->parent, widget)).

I think using a numeric position is not a good idea here, because
composite widgets are not restricted to having their children
fall into a single linear list. (Think of GtkDialog and it's
two boxes, main_vbox and action_area.) 

Plus, position is really fragile with respect to changes in the
composite widget. I should be able to add an extra Separator into the
FileSel widget widget without having that break every
GUI-builder-built program.
 
> > There is still the problem of complex composites -
> > GtkNotebook, GtkCList, GtkCTree.
> > These have extra widgets - notebook tabs & popup menuitems, clist
> > column title widgets. And the number of extra widgets is not fixed.
> 
> yep, and these can even be supplied by the user, in which case they are
> not composite children. still, i think the above mentioned method would
> apply.

If you really want reconstruction of existing widget trees in
GLE, then I don't see how that is going to work. GLE scans
a dialog, finds a bunch of non-composite children in two
different boxes. How does it know which box is the action_area
and which is is the main_vbox? How does it generate C code
to add them back there?

Regards,
                                        Owen