Re: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> well, it is actually not that easy.

Yes, now I understand better.  Obviously, I have no idea what's really
going on, but please let me try to challange you anyway. ;-)

As I see it now, composite child widgets are user interface elements
that are logically inseparable parts of the concept that the whole
composite widget represents, but are implemented as individual
widgets, for convenience.  For example, a GtkCombo should always be
treated as a whole, although it uses some child widgets to implement
its functionality.  From a user point of view, a GtkCombo has no
children at all.  Likewise for a GtkFileSelection.  But in addition to
widgets that are only implementation detail, like the list boxen, the
user can also add additional buttons.  These additional buttons are
children of the GtkFileSelection from the point of the user, while the
list boxen are not.

Soo, this makes somewhat of a sense to me.  The logical consequence is
that gtk_container_foreach should *not* iterate over widgets that are
only implementation detail.  In fact, GtkCombo shouldn't be a
container widget at all, because you can't really add children to it.
Is that a useful position to take?  I'm not sure.

With that view, the GUI builder wouldn't even learn about the
composite widgets.  All it knows is that there is a GtkFileSelection,
and that it has some attributes (args) that can be tweaked.  It can't
get at the list boxen and tweak *their* attributs because they are
only an implementation detail of the whole file selection box.

Nevertheless, I'm no big fan of too much abstraction.  There are
always reasons for responsible code to look inside some data
structure.  But the code should know that it is breaking an
abstraction barrier.  So we shouldn't probably totally hide the
composite children.

Ok, just a couple of thoughts.