Re: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Tim Janik <timj gtk org>]

On 24 Aug 1998, Marius Vollmer wrote:

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

from a users perspective you are certainly right, but since _foreach is also
used from inside gtk, and represents the only generic way of walking
widget trees as a whole, we would need to seperate the _foreach mechanism
into two different behaviours, one that covers all widgets, and one that
walks only those which are "true" widgets from the users perspective.
to avoid that split (and the need to implement a second _foreach
iterator for all containers), i proposed the composite_child flag.

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

yep, exactly. gui builders have to handle composite children carefully,
but this implies that they 1) get acces to them (most preferably through
the usual _foreach mechanism) and 2) can identify them, which the
composite_child flag takes care of.

> 
> Ok, just a couple of thoughts.
> 
> 

---
ciaoTJ