Re: possible removal of GtkWrapBox

[Murray Cumming <murrayc murrayc com>]

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?

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

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com