glooey icon indicating copy to clipboard operation
glooey copied to clipboard

Add support for tabbing between widgets.

Open kalekundert opened this issue 7 years ago • 1 comments

Support for "tab-order" is a pretty universal feature of GUI libraries. The implementation I have in mind looks something like this:

  • There would be a Tabable mixin class that would identify the widgets that should be in the tab-order. This class would help manage focus and control tab-order.

  • The GUI class would have to track all of the tabable widgets in its hierarchy and which (if any) is currently focused. It would also have to keep track of the tab-order, which would by default depend on the x and y coordinates of the tabable widgets, but could also be overridden by the widgets themselves. When the user presses tab, the GUI would find the next widget in the tab order and give focus to it.

There are a few difficulties I should keep in mind as I work on this:

  • Widgets need a way to indicate whether or not they have focus. Somehow this should be tied into the Rollover class. For buttons, the "focused" state could probably just be the "over" state. But for forms, the "focused" state should probably be something else, maybe the "down" state. That said, I can also imagine a theme where the "focused" state is totally independent of the rollover state (e.g. the focused widget has a dashed outline, and the rollover works like normal). So I should probably make focused it's own state, but provide an easy way to change what it defaults to.

  • Dialog boxes wouldn't have their own tab-order as their written now, because they're just normal widgets, not GUIs. This feature makes that decision seem like more of a mistake. I should go back and think again about making Dialog inherit from GUI.

kalekundert avatar Mar 31 '17 16:03 kalekundert

I am probably just an idiot, but I would offer these ideas:

  1. Only widgets that receive keyboard input directly (such as buttons, text boxes, checkboxes) should have a Tab order. A form should not.
  2. Because only one widget can have the focus (usually a leaf widget and not a branch of the tree), it might be OK to keep track of which widget currently has the focus by storing a reference to the widget in a single global variable, or a solution similar to a global variable. Any part of the code wants to know which widget has the focus? No need to traverse a tree, just look it up.

nandoflorestan avatar Apr 30 '21 06:04 nandoflorestan