The relayout process proceeds top-down, with parents laying out their children, which in turn lay out their children. Custom layout policy is implemented by defining a method on a generic word:
When a layout* method is called, the size and location of the gadget has already been determined by its parent, and the method's job is to lay out the gadget's children. Children can be positioned and resized by setting a pair of slots, loc and dim.
Some assorted utility words which are useful for implementing layout logic:
layout* ( gadget -- )
When a layout* method is called, the size and location of the gadget has already been determined by its parent, and the method's job is to lay out the gadget's children. Children can be positioned and resized by setting a pair of slots, loc and dim.
Some assorted utility words which are useful for implementing layout logic:
pref-dim ( gadget -- dim )
pref-dims ( gadgets -- seq )
prefer ( gadget -- )
max-dims ( seq -- dim )
sum-dims ( seq -- dim )
Warning
When implementing the layout* generic word for a gadget which inherits from another layout, the children-on word might have to be re-implemented as well.
For example, suppose you want a grid layout which also displays a popup gadget on top. The implementation of children-on for the grid class determines which children of the grid are visible at one time, and this will never include your popup, so it will not be rendered, nor will it respond to gestures. The solution is to re-implement children-on on your class.
When implementing the layout* generic word for a gadget which inherits from another layout, the children-on word might have to be re-implemented as well.
For example, suppose you want a grid layout which also displays a popup gadget on top. The implementation of children-on for the grid class determines which children of the grid are visible at one time, and this will never include your popup, so it will not be rendered, nor will it respond to gestures. The solution is to re-implement children-on on your class.