Development

Old notes

Ideas

  • let widgets manage themselfs
  • There a three kind of widgets:
    1. basic widgets that do not contain other widgets
    2. layout widgets that contain several wigets
    3. frame widgets that contain exactly one layout widget
  • Layouts in other widget sets
    • arrage subwidgets
    • tell surrounding widget how many space is needed
    • may be applied to basic widgets to control their size

Controling size

Ideas stolen from Qt

  • widget methods
    • sizeHint (prefered size)
    • minimumSize
    • maximumSize
    • hasHeightForWidth (bool == FlowWidget?)
    • heightForWidth(width) -> heigth (==rows())
  • Size policy flags (can be combined) two set of flags (v and h)
    • grow - may be bigger but does improve the widget
    • expand - more space is useful
    • shrink - may be smaller
    • ignore - don't use sizeHint()
  • "weight" (h/v) (named "stretch" in Qt)

Gtk has a "fill" flag. Having "expand" only allocates empty space while "fill" force the widget to acually use it. That way no fillers are needed. (JFYI)

widget containers

What to do with .item_types? (per-item layout information in Pile and Columns widgets) The layout information is specific to pile and columns, so I don't know how useful it would be to give it back to the user when they are querying contained widgets.

  • Move this into the widget - see above

Perhaps it would suffice to have a different interface for this data as long as Pile and Columns do the right thing when a user of the container interface inserts or deletes items.

ListBox will be a problem, it may display unbounded/lazily generated data. If the SimpleListWalker is used there is no problem.. exend the list walker interface to include the container interface?

  • Should be easy for the SimpleListWalker as it already uses a list.
  • Some special ListWalkers (like the fibonacci one) don't need to be containers
  • .getChildByPosition(self, size, col, row)