   Keyboard focus for GUI
  I'm designing a GUI system and I need to make a decision on how keyboard focus will work.My system will be a tree of widgets.  The application/root widget will poll for events and pass the current event to its children.  To keep things simple, I'm trying to avoid or reduce "focusing" as much as possible.  This is fairly easy to do for mouse input, since the events can tell the position of the mouse and all widgets have a rectangle, but not so with keyboard input.If I am displaying a set of widgets that can respond to keyboard input (e.g. text boxes) how should my system give focus to one of them, and how should keyboard focus switch between the widgets?   
  Cool! I design a GUI system just like you, and stumbled upon the same thing ;-).I too have a tree (and even tree's within leave's), so what I thought of is this: define if objects is selectable, if so, when GUI initiated, look for the first selectable object recursively. If Tab is pressed, you look for the next in the tree (and recurse downwards if leave is tree), else go up one level and keep looking for a next selectable object. This allows GUI designers to set the select order by the order in which they add new objects, instead that you geographically determine which is next...I still have my doubts, I don't like a "selectable" boolean (uglyness!), neither see I how I can go up one level from a tree...since one tree can have multiple parents in my design.   ;  A simple approach could be, since only 1 control has the focus at a time, to have a static variable in the base class (presuming each control shares the same base class) telling which one has the focus. By making this an iterator and having a (also static) list of all controls, you could go to the next or previous.For a more advanced system, for example when using multiple windows you can switch between, you could turn those static variables into class variables of the window class, and give the window class a static variable for the current window (or do that in a window manager).In case of a window manager, window and controls, when receiving a keyboard event, the window manager first checks if it's a special key it needs to handle itself (like alt+tab) and if not, forwards it to the window that has the focus. Then the window checks if it's a special key (like alt+f4) and if not forwards it to the control that has the focus. When all controls share the same base class that has an abstract function to handle input, the window manager doesn't need to know if it's a text field, button or checkbox, it justs forwards it to the control object.For mouse input, it works a bit different, it doesn't work with focus but with front-back order: first the front-most window and all it's controls, then the window behind it with all it's controls, and so on. When a control has been selected, mark that it has the focus in the window, and check if that window has the focus as well.   ;Quote:Original post by DecriusI too have a tree (and even tree's within leave's)Wait. Wouldn't a leaf with a tree inside it just be a branch? :PThis is the design I'm leaning towards: I'm going to have an Application, which will be polling for events as per my multimedia library and sending these events off to the widgets. So, this Application is the root of the widget tree.The Application would have a list of the topmost widgets (the first level of the tree).  Mouse events are fairly easy to handle: for movement I can just send them off to all active widgets and let them deal with it, while mouse clicks involves a hit test.For keyboard events, the Application can have a pointer to the focused widget, and send keyboard events directly to it.  If there's more than one widget that accepts keyboard input, the focus can be changed by clicking on the widget with the mouse (I'm avoiding Tab since I may want to use it for other things).Now I'm left with how to manage the focus. First there's determining if a widget accepts keyboard input in the first place, which is important when the GUI is first loaded and the relevant widget should have focus immediately.  Giving all widgets an acceptsKeyboard boolean is probably ugly, but I'll probably have to give my widget class methods for handling keyboard events anyway to avoid downcasts when passing along events, so one more method wouldn't hurt.  Then there's switching focus at runtime.  A widget would have a grabKeyboardFocus method.  For this to work, a widget would need a pointer to its Application, which means widgets need to know their parents.  There's nothing wrong with that, but it makes things a bit harder to keep "clean".   ;on_mouse_click  root_object->handle_mouse_event()handle_mouse_event()  if_object_visible_enabled_etc    if_coordinates_are_inside_object for_each_children->handle_mouse_event(recursive) if_can_be_on_front   parent->bring_control_on_front()   bring_control_on_front() //make it the first child in the list if_is_front_most   if_can_have_focusset_focus if_can_have_keyboard_input  keyboard_events_will_arrive_to_this_control_onlyMore or less how I did it long time ago. It requires you to tweak it a little   ;Quote:Original post by MichaBenA simple approach could be, since only 1 control has the focus at a time, to have a static variable in the base class (presuming each control shares the same base class) telling which one has the focus. By making this an iterator and having a (also static) list of all controls, you could go to the next or previous.That's what i do in my GUI. Except i haven't implemented tabbing to next/previous controls so i don't need a list to iterate through. When a TextBox is clicked, I just set the static keyFocus variable to that object.   