Re: possible removal of GtkWrapBox

[Tristan Van Berkom <tristanvb openismus com>]

On Mon, 2010-10-11 at 13:04 +0200, Murray Cumming wrote:
> On Mon, 2010-10-11 at 19:54 +0900, Tristan Van Berkom wrote:
> > On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote:
> > > On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote:
> > > > Furthermore, the gimp's newer versions is now using GtkToolPalette
> > > > in place of the older wrap-box (the gimp had been using a similar
> > > > wrap-box widget to wrap items around in one of it's toolbars).
> > > 
> > > Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or
> > > some similar code?
> > > 
> > 
> > Unfortunately it cant be done that simply (actually; I initially
> > wanted to implement GtkSpreadTable in terms of a GtkBox subclass 
> > with 'n-lines' child GtkBoxes lined up in the opposite orientation,
> > i.e. an hbox filled with vboxes... this idea would have presented some
> > problems when it would come to requesting and testing different
> > configurations).
> > 
> > The main problem here is that the GtkToolPalette is expected to
> > contain toolitems, and calling gtk_container_get_children on
> > it should generally return the toolitems, anything that invokes
> > the forall vfunc expects toolitems, not a wrapbox (also calling
> > gtk_container_add/remove() on the toolpalette is not expected
> > to add/remove the child wrap-box).
> 
> Can't some vfunc implementation make it return the indirect children,
> instead, making GtkWrapBox purely implementation?

I think whatever implemented along those lines is going to be
a mess if successful at all.

For instance, in size requests and allocations we would need
a real hierarchy (involving the wrapbox ofcourse), also when
propagating events through container children we need to use
the same logical heirarchy (propagate expose, child focus etc).

Then when adding and removing we want to pretend the wrap-box
isnt there... with the exception of when the toolpalette gets
destroyed and then we want to destroy the child wrapbox and not
only its children... probably some other implicit things 
about maintaining a logical hierarchy I'm missing (oh and maybe
we want gtk_container_list_children() to also pretend the
wrap-box isnt there, which is a call to forall() but then
how do we detect the difference between a forall() call 
for external user code or a forall() call that propagates
expose events or such ?).

Anyway that's the kindof road we would be walking down, unless
the toolpalette were documented to be a composite widget with
an internal wrap-box (or internal wrap-boxes in the palette
groups, either way)... in which case we would have extra
apis for adding and removing children of the internal wrapbox.

(kindof like GtkDialog must do to get at the internal vbox
and action-area), but this approach would also be a big
api break...

Cheers,
     -Tristan

> 
> > So I would have to say only the latter is really possible, i.e.
> > the toolpalette should use similar code as the wrapbox.
> > (this case kindof shows one of the advantages that Clutter has
> > in terms of layout managers being separated code from the
> > actual containers).
>