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). > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list