2

I'm trying to write a GUI library for a project (also for learning purposes) from scratch (in C++), and it's working pretty well, but since this is my first attempt i feel that the design of the event system isn't that great.

basically, how i'm handling events now is that whenever a mouse click occurs i iterate over all the Widgets (buttons, for example) and test whether the mouse coordinates reside in one of them, and if so i call the event callback (a function pointer) which is stored in the button class itself!

so i was thinking of a different (better?) design:
What i want to have instead is an Event-Queue where whenever an event happens (a button clicked for example) i do the same thing as before (i.e. find out which button was clicked) and then construct an object of that event (i.e. ButtonClickedEvent) and add it to the queue and handle it later on, after rendering the frame, for example.

and this is where i'm getting confused about it.
how should i structure the whole thing without creating a mess? in other words, is there a standard-ish way of doing it?

i've been looking around for some info about this but all i find is how events can be handled in existing libraries (like java swing, QT, ...etc).

so if anyone here could explain how it works, that would be much appreciated!

Improve this question
9
  • 3
    Most GUI libraries are wrappers around the operating system's own API, so the typical approach would simply be to use whatever the O/S provides already (i.e. by hooking directly into its API) - the OS will always be better at doing this than anything that you'd be able to build yourself simply because the OS is already responsible for managing those controls/components and already owns the communication between those and your hardware inputs.
    – Ben Cottrell
    Commented Nov 26, 2019 at 13:00
  • [pssst - just a hint. Instead of iterating, consider using a bidimensional array as a map for the screen, with a 1 pixel = 1 position in it. Add the click event pointers to the cells of the array, and voilà - direct access to everything, no iteration needed. Memory is cheap!]
    – T. Sar
    Commented Nov 26, 2019 at 13:28
  • @BenCottrell Actually in my case that wouldn't workout (not without a lot of headache, atleast), since the library is suposed to be cross-platform. thats why i'm trying to "write one from scratch".
    – user346466
    Commented Nov 27, 2019 at 11:22
  • @T.Sar-ReinstateMonica That's an interesting approach, actually. but how would that work if the GUI layout changes? if you switch to another menu for example.
    – user346466
    Commented Nov 27, 2019 at 11:24
  • 1
    @IshoAntar Then you update the map! Just change the points of the edited area (which you know, since you're drawing it in the first place) to point to the correct ones and you're set. Once the layout changes/menu closes, you'll have to redraw again - and thus, update the pointers once more.
    – T. Sar
    Commented Nov 27, 2019 at 11:27

1 Answer 1

Reset to default
4

For this answer I will assume that widgets are not, and cannot be operating system windows.

Appetizer: keyboard input.

The idea is that some widget has keyboard focus. You keep track of what widget it is (if you have the means for widgets to indicate they support keyboard input, you do not give keyboard focus to widgets that do not). Then when the event is registered, you send events to widget with keyboard.

Main course: pointing input (mouse, touch or similar).

Yes, you can iterate over everything and check bounds. That is not great.

It is better to use space partitioning. That is you will create a tree structure where each node represents an area of the view port/window. The root is the complete working area, and the leaves match the are of the widgets. Now you can navigate the tree to find out what was clicked.

It is possible to do it even faster: you create a bitmap/texture where the color of each pixel/texel is an id that maps to a widget. Then you simply read them as needed. I seem to recall some browsers do this, not sure.

Whatever structure you pick, don't forget to update it when widgets move.

Side dish: event queues.

Yes and no. I mean, you probably have a message queue from the operating system already. The usual solution is to rely on that.

Be aware that you might be interested in placing something in the queue (so that other thread can use them to place code that interacts with the UI, so that the UI thread handles it). If using the operating system queue for that is not viable (for example, you want multiple per window, for whatever reason), you create your own.

Drink: event bubbling.

The widget can mark the event as handled or not. If it is not handled, you send the event to the container widget, and so on. That is you bubble up the event.

However, if you want to handle preview events, you propagate them in the opposite order. This can be useful to allow containers to intercept keys, for example.

Dessert: rendering.

How are you going to allow widgets to paint themselves? Remember, I am assuming here they are not operating system windows. You can give them an API that allows them to do graphic primitives. Alternatively, you can give them a graphics buffer/bitmap/texture and let them use it however they want. And, yeah, you need to know the are they take of the window and you are going to run a callback for them to execute their code. You probably also want to do double buffering and vertical synchronization. Yet, that is beyond the scope of this question.

Improve this answer
3
  • Thanks for the detailed explanation, strangely enough, i have most of what you explained already in place (again since this is my first real project, i needed someone to reassure me that i'm on the right track :)), First, your assumption was correct, the widgets aren't operating system windows, regarding the keyboard input, i don't have such a thing at the moment but will have to work it out, in the near future. Pointing Input i guess i didn't explain myself quite well, but that's what i'm doing, start from the root, and keep checking which child container was clicked until i get to the....
    – user346466
    Commented Nov 27, 2019 at 11:31
  • actual widget. Event Queues again since it's cross-platform i guess i'll have to write my own (i don't think that would be much of a trouble, though). Event Bubbling, i'm already using such a functionality to stop passing the events around when they are already handled, just didn't know it was a thing :(. Rendering, The first thing that i did (as a part off my learning process) was to build a 2D-Renderer using OpenGL, so i'm not concerned about that :).
    – user346466
    Commented Nov 27, 2019 at 11:35
  • 1
    @IshoAntar By the way, for space partitioning, you can have nodes that do not match any of the widgets. In fact, I would suggest Binary space partitioning if you are going that route. Speaking of OpenGL, read how video games handle click on a 3D enviroment.
    – Theraot
    Commented Nov 27, 2019 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.