Sorry, but I'm muddying the waters again- as before, please respond with feedback.
Attempting to add a gadget to a layout agnostic to its type is currently impossible. This makes all general purpose gadget layout code a big hack (see my gadgets.layout for examples.) Why? Many layout gadgets keep extra information for their children. In grids and frames, that's the position. In tracks, that's the fill. And future libraries are likely to need other information. I propose the solution (coming from a haskell background) of a new protocol for gadget layout. Layout Protocol: - layout-gadget This should be a mixin class for layouts. Only members of the class should implement the following words. - add-gadget For many gadgets, this already is a general purpose layout word. But for others it's more low level, not to be called by the user. These occurrences should be replaced- perhaps call (add-gadget) or something. Rather, calling add-gadget on a layout that has extra information should add with some kind of default. For tracks that would be f. For grids that could be the next unfilled position. It's up to the layout. - add-gadget-at Insertion behind other gadgets is common enough. However, one can't just change the position in the children vector- one needs to change the extra information too. This word, implemented by a layout, should insert a gadget and its extra information at the specified index. Across layout implementations, the extra info can be thrown away and a default can be used. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
