From my research for our UI framework, neither of them. If you want to speed up your UI input handling, you should use a spatial positioning data structure and register every UI element which is able to receive input. Then when input is processed, you can make a quiet fast lookup into that tree and determine the cluster of UI elements which might process the input. This is at least our plan to speed things up.

I also prefer data driven UI over inheritance, even if the later one is more easy to implement, data driven has the advantage that rendering and layouting could be solved from a system and so you can have faster iteration because your UI is just data which don't need recompilation

@wintermute Your container can select the affected child based on its covered area and the position in the event.

I have no idea what you want to do with the mouse up/down/moved methods, what makes you think I don't move the mouse at the same time? (Mouse down, move to other widget, mouse up.) In my view, mouse clicks and moves are window things rather than widget things.

Also, you realize the application rather than the widgets have the data you want to display right? (That is, do you really want to copy data between widgets and application all the time?)

Gotanod said:
I have a question about how you implement the drag&drop of a window with different entities inside, - does the parent window send events to their children? - or, you define all together in one entity (window+scroll bar+button+text)?

This is something WIP at the moment but what I can tell is that we have a root element per tree, which is a window. But this is taken into account only if we need to determine the back color for example. That tree is computed into different trees, a layout tree, a render tree which contains elements which have to be drawn only and the action tree which contains elements which have interaction behavior. Whenever an input message arrives from the OS, the tree action tree is called for the position given in the input message and all elements, ordered by z-index are returned and asked to handle the input from top to bottom

Wintermute2 said:

Hello,

I'm writing a simple GUI with SDL (1.2).

According to you, what is the best solution ?

For simple GUI's it doesn't matter what you do. If you ever have overlapping GUI elements, then you may want option 1) and let the container work out which element is being hit, based on the element which is ‘on top’ .

For the actual mouse / keyboard events I've always used message passing, which is how Windows works (WM_MOUSEMOVE etc). So you might have something like this (pseudo code).
Makes testing very easy, because you can just hammer your UI with random mouse / keyboard events in an attempt to break it.

while (SDL_PollEvent(&test_event)) 
{
     Read SDL mouse / keyboard event... convert to our own custom message format 
     Gui->ProcessMessage( message );   // gui could be a container
      

}
// then inside you GUIContainer 
GUIContainer :: ProcessMessage
{ 
	switch (Msg->CommandID)
    {
        case LEFT_BUTTON_DOWN:
         if ( PointInsideControl ( this ) == false)
           return;
         else
         {
            // pass the message on to child objects
         }
          
    }      
}

If you ever end up with the ui getting bigger, worth looking at topics such as composition vs inheritance. For widget layouting, Facebook Yoga is very good https://yogalayout.com/