Development

This page discusses features to be implemented. Take with a grain of salt.

Container Widgets

The following widget classes will inherit from a new ContainerWidget class:

  • Pile
  • Columns
  • Overlay
  • WidgetWrap
  • ListBox
  • HListBox (when completed)

Container widgets will provide a uniform way to access their children and will share much of their rendering code by describing the child widget layout to the ContainerWidget class at a high level. Inserting and removing children will be possible with some of the widget types.

  • get_focus(), set_focus()
    • .set_focus() does accept either a widget or a number for some classes (GridFlow, Pile, Columns)
    • There is Column.set_focus_column(), Column.get_focus_column()
    • Frame.set_focus() accepts one of 'header', 'footer', 'body' - keep and implement new properties?
    • .get_focus is not always implemented
  • Pile and Columns should be more similar
    • .focus_item (widget) <-> .focus_col (int)
    • .item_types <-> .column_types
    • .get_item_rows() <-> .column_widths()

New container API:

  • .focus property (GET) that is the widget that has the focus. None for leaves. DONE
  • .focus_position property (GET/SET) property that is a position value that this widget understands. Raises IndexError? on GET/SET for leaves or when being set to an invalid value. DONE
  • .contents property (GET) (SET as well in most cases) is a mapping or list-like (for simple containers) object whose keys are positions and values are (widget, container_specific_options) tuples. container_specific_options may be created from .options() class method on the container class, for forwards compatibility.
  • [x] (a.k.a. .__getitem__(x)) is equivalent to .contents[x][0].base_widget

"Maybe-later" additions to container API:

  • .get_focus_path() method list of focus positions down to the leaf widget, skipping all decoration widgets (they only ever contain one item)
  • .set_focus_path(x) set the focus positions along each widget in the path. useful for restoring a value previously returned from get_focus_path(). raises IndexError? on failure
  • .get_descendant(x) get the base_widget with path x
  • .set_descendant(x, w) attempt to set the base_widget at path x, returns the original base_widget that was replaced. raises IndexError? or ContainerWidgetError? on failure
  • .contents_from_focus(reverse=False) iterator over child (widget, position) tuples

eg. 

bottom_focus = w.get_descendant(w.get_focus_path())
one_above_bottom_focus = w.get_descendant(w.get_focus_path()[:-1])

Short cut handling

For menus (and perhaps for other widgets too) it is very handy to have short cuts (like alt F for the File menu entry). For the API it would be nice if the widget itself could decide which short cuts it wants to register for. We could even use something like Menu(['_File', '_View', 'F_orget'], underscore_shortcuts=True) and make the widget do the work.

Problems:

  • The widgets that should recieve the short cut are not in the focus and don't get a keypress call.
  • The right place to handle these keys may vary (top level, dialog, menu (not menu item)).
  • We don't know where the widget is and how to switch the focus in all the surrounding widgets

Current plan for Development:

  • Include shortcut keys in the Canvas objects rendered by widgets.
  • Include position information and shortcut information in the CompositeCanvas object's "child" list.
  • Overlays would drop shortcuts from their background widget (since they can't focus background)
  • Implement container interface for all composite widgets.
  • All shortcuts and a way to set focus is now available from the topmost composite widget.
  • Would not allow shortcuts from widgets that are not visible (IMHO a good thing)