An immediate mode set of widhets based on OpenGL (X11/GLX)
SUMMARY
This is me showing off. You do not want to use this software unless you really know what you are doing. You probably also do not want to try and understand how it works. But, in a nutshell...
It uses the "object oriented" programming paradigm in C++ to build an abstract "Widget" class, from which other classes derive properties.
It uses a "bridge pattern" to separate the abstraction that is the widgets from the rendering pipeline, in an effort to keep the separate (say you want to display this in a VR headset just as you would on your X11 or other renderable with OpenGL, this pattern allows you to do it, as well as porting it across OSs, like to Windows and Apple).
It has its own organic font, which I have promptly derived --without breaking laws-- from the open source fonts.
There is both C and C++ code in here. The C code is from my "INXLIB" project, and it is responsible for managing the X11/Xlib part, as well as some "compatibility mode" OpenGL rendering lists. The OpenGL context is opened in compatibility mode in order to accommodate the OpenGL 2 rendering pipeline but also to support how these widgets are rendered. Mixing the two is not a problem, as a lot of legacy software built on OpenGL would not work otherwise.
Once the window is opened, an event-loop captures X11 events and processes them. It passes clicks, mouse motions, keyboard button presses, focus in/out, and reshaping events of the window to "callbacks" that are set at compile time -- as they should be. A user of the INXLIB library should be able to program the callbacks, and this is what I did here to port the widgets on top of that library.
At rendering, the object hierarchy is maintained for how events are passed from the window, to the "root" widget, and subsequently to the child widget, all the way to the "active widget". To follow the events you can capture the terminal screen output and observe what the helper text (in green and in yellow) displays in the window. (In production, you would turn that off.)
I have raw-injected a C code to render a spinning cube (in a perspective projection) in the window, which gives you an idea of how the hardwired delay yields a smooth framerate.
To compile and run, just make all and run it. Things are simple.
L-CTRL and ESC to exit. But do click around and move the widgets and play
with them, including their individual menus.
I will likely not develop this code any more as I will be moving away from the "fixed rendering pipeline" and to a pure "programmable pipeline" for all my OpenGL rendering. And I may retract this from the open source realm, as the license is also too restrictive for anything beyond learning a few things. But I hope it helps people.
IN 2025/09/17 (Published on Github)