GUI Programming | FomenkoGUI Programming<br>By Alexandre Chêne|August 06, 2026

This post is an overview of my choices when programming my own GUI library, this is not a tutorial.It’s been a while since I wanted to own the GUI stack, despite having experience with making GUIs from scratch, I never had the time to properly pause what I was doing and be a bit serious with it. But for the past month or so, I was making exactly this, a GUI library, which is now what I use for my current game editor and what I’m gonna use for any forthcoming projects as well. And here’s what it looks like:

Some of these clips are taken from an upcoming game I am working on.<br>The main direction I gave myself was to speed up the velocity of writing UI code. I should be able to write UI easily, quickly and without having to think too much about states, or managing positions of UI elements. Another design point; because I will (potentially) use this code for many of my projects and for a long time, it’s important for me to be pleased while using the UI; so I want some kind of juicy effect or smooth transition while interacting with widgets.So I headed writing what is commonly called an “immediate-mode” GUI system. This style of writing UI code matches my own style in general, it’s procedural and pretty natural to integrate with your own code logic. But there’s not a single way of implementing an immediate-mode UI system. You could design something which is fully stateless, and let the user code manage this part, but then the user has to manage more things, like positions and sizes of widgets, input cursor position, and more. A balance must be found, between what I put in the user’s hands from what I encapsulate in the GUI library, without constraining (too much) what UI we can build.And one thing I noticed when working on my own game editor or other diverse projects; the majority of widgets could follow simple layout rules instead of having to manually assign positions and sizes to them. That’s why I implemented an internal auto layout system. A bunch of functions are exposed to the user in order to change on the fly the layout behaviors. Like to put your next widget on the same line as the previous one, or to take the full row, or start a column mode, etc. You can also escape this system by providing a rectangle (meaning a combo of position and size), or semi-escape it by just providing its sizes.In terms of actually drawing the UI, I wanted something simple as well, no signed distance field for rounded corners or no complex shader to set. Instead, just a bunch of vertices to draw. It’s simple that way, and versatile enough to do everything I wanted. The price is a bit more vertices to draw, but it’s pretty anecdotic, plus I use some tricks to lower the vertex and draw call count, which I’ll describe later on.Before explaining the core mechanism of my code, it’s important for me to state that I was inspired by many others. From Casey Muratori which is the first who formulated and brought to the public the concept of immediate-mode GUI, but also Omar’s Dear ImGui library which is probably the most famous implementation of an immediate-mode GUI. Less known because not yet public, but the Jai module ‘GetRect’ written by Jonathan Blow was very valuable to me, I particularly liked reading his code, there are some interesting tricks in it. Also, the whole UI post series written by Ryan Fleury was highly interesting, and I recommend you to read it as well.Alright, let’s dig into my own implementation now!Handling Inputs<br>One of the first things I had to do, was to get input events from the underlying operating system. Without that information I couldn't know mouse positions or if the user clicks somewhere.I didn’t necessarily need all the input events. I needed the mouse positions and its click states (pressed or released). I also needed some specific key events to make keyboard navigation possible, like tab, escape or the return key. To make copy/paste possible, I needed modifier states as well (shift, ctrl, etc).This library doesn’t know anything about the underlying platform, so by itself it cannot pull those input events. Instead, the user can use a bunch of exposed functions to pass io events to the library. So for the mouse positions, mouse wheel, or modifiers, there are set_mouse_position or set_modifiers. For key and click state events, I’ve a single enum mixing mouse and keyboard keys. To set them, it’s done with set_key_event function, where I map a key to its state. Here’s an example which loops over SDL events:while SDL_PollEvent(*event) {<br>if event.type == {<br>case .SDL_KEYUP; #through;<br>case .SDL_KEYDOWN;<br>down := event.key.state == SDL_PRESSED;

if event.key.keysym.sym == {<br>case .SDLK_ESCAPE; set_key_event(.ESCAPE, down);<br>case .SDLK_BACKSPACE; set_key_event(.BACKSPACE, down);<br>case .SDLK_RETURN; set_key_event(.RETURN, down);<br>// ... Same for other keys.<br>}As you can see, it’s straightforward here. Internally, key states are stored in a...