I'm designing a GUI system where I use a Widget class to represent everything. A widget can have child widgets (buttons in a panel, label in a button) and my game feeds the root widget input events from SFML or whatever. When given an event the widget does an action in response then (optionally) hands the event down to its children.

[source lang="cpp"]class Widget
private Widget parent
private Array<Widget> children

// True if mouse hit this widget or any of its children
public bool mouseDown(int mx, int my)
bool gotClicked = false
bool blockChildren = false
bool childGotClicked = false

if visible and enabled
if contains(mx, my)
gotClicked = true
blockChildren = onMouseDown(mx, my)

if not blockChildren
// Children are ordered front to back.
// Children are not necessarily inside the widget.
for c in children
childGotClicked = c.mouseDown(
x - this.x, y - this.y)
if childGotClicked
gotClicked = childGotClicked
break

return gotClicked

// True if mouse event is blocked from the children
protected virtual bool onMouseDown(int mx, int my)[/source]

In addition to mouseDown, widgets will respond to mouse drag and mouse up events. I'm going to ignore mouse move events so that I don't have to worry about enter and leave actions, and because touchscreens are teh futures.

I'm thinking about good ways to handle keyboard and mouse focus. A widget gets keyboard focus either programatically or by being clicked, and has all keyboard events forwarded to it. Mouse focus is something I'm thinking of in terms of widgets like scrollbars responding to mouse drag events even when the mouse is outside of them. I figure that would be like one widget receiving all mouse drag events, so the widget would have mouse focus in the same way a widget can have keyboard focus until the next mouse-up. Plus I want the ancestors of the focused widget (either keyboard or mouse) to see the relevant event first like with the mouseDown event.

One idea I came up with is representing focus state with four variables: hasKeyFocus, hasMouseFocus, keyFocusedChildIndex, and mouseFocusedChildIndex. A widget responds to a key if its hasKeyFocus is true or its keyFocusedChildIndex is greater than -1, and the widget passes the event along to its child at children[keyFocusedChildIndex]. A widget uses its hasMouseFocus and mouseFocusedChildIndex variables in the same way for mouse drag and mouse up events.

Is this a good way to handle focus for key and mouse drag events?

I said I want all ancestors of the focused widget to see the events directed at it. Suppose we have a widget tree like this:

• Main Panel
  
  
  
  • Panel A
    
    
    
    • Button A
      
    • Button B
      

Panel B

If Button A had the focus, I'd want the event processing to go Main Panel > Panel A > Button A, in that order, instead of the event going straight to Button A.

As for keeping the information in a centralized location, I want as little overhead as possible. I don't want to wrap my widgets in a "gui manager" class. The application just needs to keep a reference to one or more root widgets, where a widget can be anything from a single button to a large control panel.

As for keeping the information in a centralized location, I want as little overhead as possible. I don't want to wrap my widgets in a "gui manager" class. The application just needs to keep a reference to one or more root widgets, where a widget can be anything from a single button to a large control panel.

If anything, I think a central location would actually reduce overhead. If you don't want a manager or globals, you could go for a static members.

I'm not clear on what you gain by complicating your focused event dispatch in this manner?

How is focus normally represented in GUIs then? And how are dragging scrollbars normally handled?

I'd still like the ancestors of the focused widget to see the event before the widget itself sees it though.

One example I had in mind for my project is a panel with a draggable row of pictures. I can either click on a picture to "select" it and have some data show up somewhere, or I can grab and drag anywhere in the whole row panel to scroll it.

That is, I'd want to be able to click-and-drag anywhere inside the panel - including inside a picture - and drag the row of pictures around. Clicking and not moving the mouse while over a picture would be interpreted as selecting the picture.

I figured I could make this work by letting pictures under the mouse (if any) get the focus but let the parent panel see the events sent to them. That way if the mouse is dragged beyond a certain threshold I can have the panel do its scrolling action even when it's a picture that has the actual focus.