Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm developing a set of simple widgets for a small (128x128) 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 next member). 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:

  1. How can I manage focus for these widgets?
  2. Am I making this too complicated?
share|improve this question
    
must a widget be able to know which widget would next get focus, or are you simply assuming that's the best way to do it? Is there a reason for that particular requirement? –  Bryan Oakley May 5 at 19:22
    
@BryanOakley When I compose widgets in a menu and press to "right" button, the widget system should be able to figure out which widget would be the "next" to get focus. The next member of a widget serves two main purposes: hierarchy and ordering. I could implement a "Tab" list, but that would occupy additional memory (would be cleaner, though). –  Christoph May 7 at 9:35

3 Answers 3

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.

share|improve this answer
    
I'm glad I'm not the only one who wants to implement simple widgets, but, to be honest, your answer didn't really help me. What would I do with a widget that is only used for "grouping" child widgets, like the menu I outlined in my question? It wouldn't accept focus "directly", but only for switching to the next menu item. This is not a thing that a menu item should know about. –  Christoph Feb 20 at 10:01

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.

share|improve this answer

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.

share|improve this answer
    
Creating an array is difficult for this application. When widgets are created, the array must either have space for additional widgets or needs to grow. That would probably invalidate all widget pointers created so far. Also, keeping a hierarchy is necessary for example when I want to hide/show composed widgets. I'm afraid your suggestion would make things more complicated than necessary, and hard to manage. –  Christoph May 7 at 9:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.