First of all, in the last few posts I have written I was discussing about the differences and advantages of event-based systems against poll-based systems. This has NOTHING to do with object oriented versus procedural programming. It's quite easy to make either a procedural event-based system or an object oriented poll-based system (and there are a lot of examples of both). This has also NOTHING to do with the doWidget paradigm most IMGUI tutorial teach.
Quote:Let's say you have 5 windows w1 to w5 and user clicks on the close_window_button of w5.
- In polling methods, all 5 windows would have to poll the GUI system to know if they have to close.
- In eventing methods, no polling is done by any window and only w5 receives an event from the GUI input system telling it to close.
That's the main advantage of eventing over polling (Function calls overhead reduction)
Since most events have effect on very few widget each time they are triggered, it is quite important to have some mechanism to query all the widgets who must handle the current event. If this mechanism is implemented (in the library or in the application), then you can write something like that:
Window activeWindow = windows.getActiveWindow(event);activeWindow.update(event);
This is actually what your event system probably do. The code looks quite simple and there is no overhead compared to your event system (quite the opposite actually).
Quote:
I don't understand your point here with respect to scatter:
/* SOURCE CODE ELIMINATED... */
Another bonus here, I can derive a new button type that behaves slightly differently when OnMouseOver is called. Of course you can do this with IMGUI too, because you can do anything you like if you write enough code. We're using Turing Machines after all :p.
Well, I was actually thinking about a specific API. Your example is fine, but you can do exactly the same in a poll-based system. The only difference is that the code which calls that functions is explicit instead of being hidden in the library.
Quote:
I would prefer the above to:
voidIMGUI::DoComplexGuiComponent(a, b, c, d, e, f, g, h, i, j, k, l){ if(a) if(c) else else if(b)<---- cyclometric complexity is bad.}
Why do you think a polling system update function should be written like that? People learned to write clean and readable code long ago. You can clearly use structures or classes to reduce the number of parameters and you can break your logic in several functions if it make sense. Bad code is just bad code, whatever paradigm you are following to write it.
Quote:That's an interesting point Burnhard about cyclometric complexity. The UI code the user deals with directly has fewer control flow paths in an event-based system, since it's the library that handles control flow. That can be a really important thing when you're trying to debug something or read old code by tracing control flow paths.
I have already discussed about the quality of code. I think you are really overstimating the additional complexity. You surely need some additional logic, but you also have a little more flexibility and control in how your code handle the events.
Anyway, I have used several event systems in the past. Some were really good and were a pleasure to use, others were really bad. I think you can write a good or bad API using both methods, but I prefer to have control over the application and GUI main loop.
