On Aug 7, 2009, at 11:10, Sam Anklesaria wrote: > 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. ... > - 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.
I don't know Factor or (whichever) Haskell UI libraries, but Java AWT works like this as well: a component in a container has an extra value which is the layout info, and it's up to the layout manager to interpret that value. Works reasonably well as far as I know, which isn't very far. -- Kevin Reid <http://switchb.org/kpreid/> ------------------------------------------------------------------------------ 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
