I’m developing a set of simple widgets for a small (128×128) display.
For example I’d like to have a main screen with an overlay menu which I can use to toggle visibilty of main screen elements. Each option would be an icon with a box around it while it is selected. Button (left, up, right, down, enter) events should be given to the widget that has “focus”.
Focus is a simple thing to understand when using a GUI, but I’m having trouble implementing this. Can you suggest a simple concept for managing focus and input events? I have these simple ideas:
- Only one widget can have focus, so I need a single pointer to that widget.
- When this widget gets some kind of “cycle” input (as in “highlight the next item in this list”), the focus is given to a different widget.
- a widget must have a way of telling the application which widget the focus is given to next.
- if a widget cannot give a “next focus” hint, the application must be able to figure out where the focus should go.
Widgets are currently structured like this:
- A widget can have a parent, which is passed to the constructor. Widgets are created statically, as I want to avoid dynamic memory allocation (I only have 16kB of RAM and I’d like to have control over that).
- widgets have siblings, implemented as an intrusive linked list (they have a
nextmember). A parent has a pointer to the head of its list of children.
Input events are arguments to the widgets buttonEvent methods which can accept or ignore that event. If it ignores the event, it can pass the event to its parent.
My Questions:
- How can I manage focus for these widgets?
- Am I making this too complicated?
2
I think you are making the problem more complicated than it is. Create an array to contain a reference to each widget. Append widgets to the array in the order they are created. The next widget to get focus is just the next widget in the list that is focusable.
You can then add functions to raise and lower the relative ordering of widgets for when you want to traverse them in a different order than they were created.
If you want to get fancy, give each widget a “canAcceptFocus” method, so moving focus means going to loop over the widgets, calling the method until one of them returns true. This way a widget can decide for itself whether it should be focused (such as returning False if its own status is disabled, or if it’s just a simple label widget, etc). It doesn’t have to know about any other widgets, it just has to know if it can be focused or not.
1
I implemented a system like this in the past and your design is very similar to mine. A hierarchy of widgets (widgets can contain child widgets), child widgets know who their parents are, there is only one globally focused widget at any time and it must be a leaf widget (no children).
The difference in my design was it was possible to specify which widgets would come into focus by populating each widget with a map to other siblings.
For example. My input allowed up, down, left and right so each widget had up to 4 siblings mapped to each of those commands. Widget A could have a “right sibling” that was Widget B and Widget B could have a “left sibling” that was Widget A. Any command issued would check the current focused widget’s sibling for that command. If it did not exist, focus did not change. If the sibling mapping did exist, the focus was changed.
If this proves too expensive for you memory wise you could store the sibling mappings in the parent somehow.
1
Here is what I have now, and I think it’s not over-engineered and does its job of managing focus (i.e. which widget gets my button events?)
- I have an abstract widget class that maintains a static pointer to an abstract widget,
focus_. - A widget has a protected property,
acceptsFocus_that is used to enable focus for that widget (or not). This is more or less a constant property, I think. - Focus can be given to a widget with a public method. If it doesn’t accept focus, focus is passed to the parent widget (which in turn can accept focus or not, you get the idea). This sets the static
focus_to point to the first widget that accepted it. - When a widget is constructed, it gets focus. This might not be necessary, but I thought it might be handy just in case I forget to set the focus to some widget when the whole app is initialized. On the other hand, I might end up wondering why something unexpected happens when I press a button.
If I don’t totally mess things up, this ensures that button events will eventually end up being handled by something.