That's easy enough, just use something like this pseudocode:
on_gui_event(event)
pass_event_to_widget(current_focus_widget, event)
pass_event_to_widget(widget, event)
if(widget.parent)
if(pass_event_to_widget(widget.parent, event))
return true
if(widget.wants_event(event))
widget.handle_event(event)
return true
return false
So rather than pass events to the root widget, where a widget first processes the event then decides which child to pass the event to, I'd pass events to the focused widget, where a widget first sends the even to its parent then processes the event.
Regarding your picture panel, the functionality of scrolling when the user clicks and drags and selecting when the user clicks but does not drag can be implemented using the single focus widget approach in a number of ways. The first obvious way is to not use widgets for the pictures in the panel and instead have the panel draw the pictures itself, as well as perform the required mouse hit-testing. This approach is used a lot. For example, tabs in a tab control are not individual widgets. There is no set criteria, but in general, if it's "a component in a list" kind of thing and doesn't require complex internal user interactions, it's not a widget, but an internal component of the parent widget.
Hm. My example of the scrollable row of pictures would have been implemented with a panel that contains a row layout widget, with the row layout widget containing a bunch of image widgets, If the panel becomes a single widget without focusable sub-widgets then would it still be possible for me to reuse the image and row layout widgets? I want to leverage composition as much as possible throughout my GUI system, e.g. buttons contain text labels.
