The ultimate targets of this project are embedded systems, mainly medical devices, and the desktops used to develop them. Nothing else matters.
A cross platform widget based library that is immediate mode and actually free. Will provide support for serial/parallel ports still used in embedded systems development. Support for other devices will be added as time and resources allow.
Project is hosted on SourceForge where professional projects reside. Please check the blog there for progress and why certain decisions were made.
Unlike some other "open source" projects, there won't be a commercial version of this nor will we adopt an "everyone must buy a license" definition of Open Source.
Architecturally we are going to get here:
Qt, CopperSpice, even MFC are legacy frameworks. You can read this blog post for background on how we got here, but the gist of it is as follows:
Event Driven is the massive switch. No matter how many layers it gets hidden under, there is a Main Event Loop. It must execute in the primary thread. Any events, be they mouse movements, serial comm notification, frame work (vs. OS) signals, screen paints, etc. must all execute in this primary thread. Any threads you create, unless you specifically force them to a different core in the CPU, will have affinity for your core. That means, in general terms, your application will use only one core of your 4, 8, 20+ core machine. One of the big reasons Docker containers have become so popular is, generally, each container can run on a different core so you can keep using your single threaded Main Event Loop application framework.
That doesn't, however, fix the problem in the embedded systems world where you can have a flood of data over a serial port or from various sensors, that all needs to be processed before buffers overflow and data is lost. Not really a great thing for the surgical robot to not really know where the scalpel is when it is cutting on your heart.
Project is being developed under Eclipse Public License 2.0 with additional restriction because LGPL v2.x is far too restrictive and MIT is a bit too loose. Additional restriction: You cannot bundle this code with any library you charge money for. The days of companies like Qtc selling Open Source libraries as commercial libraries ends here.
SDL3 will be used for our rendering layer. This library provides graphics, keyboard, mouse, and audio allowing us to ignore the low level drudgery. SDL3 supports a laundry list of operating systems from Windows XP to Linux to macOS to QNX, even Emscripten if you wish to cross compile for Web. Note: serial ports and other hardware devices will most likely not be accessible from a Web compile.
Project will be UTF-8 based, not UTF-16.
Just take a good look at any C++ application framework you personally like that has been around since the late 1990s or very early 2000s. There is an ocean of legacy baggage, not the platforms they still support, but the classes they rolled their own on and cannot jettison now because they have an installed base.
This is 2025. Yes, in 1994, little, if any, of this existed, so libraries had to roll their own. Today requires a flash cut to the standards we have now. We need a UI library with some core data type classes that just provides wrapper/interface classes to industry standard libraries for everything else. Time to admit specialization is a good thing. The era of "If I need insert-something-here I will write insert-something-here" has to be over. That's how we got where we are. Using tools that were designed for OS/2 and Windows 3.x that are not designed for today.
This is brand new project and we are taking baby steps. Today the license got chosen. Copyright and header stub will be created along with the dependency install scripts. Remember the focus of this library will be to create Widget and specialty classes for desktop and embedded systems development. We will choose to write wrapper classes for industry standard Open Source specialty libraries with large developer bases. If someone has already built a solid, wide bridge, drive over it, don't insist on building your own!
First classes will be
After that we need a design meeting for how we wish to handle styles. It will not be with CSS! Once styles are decided, graphic widget classwork can begin.
Eventually we will create a wrapper for Servo. That will be in front of support for DICOM images and graphing classes.
Every graphing package I've ever used for Qt sucks. They all have a home hobbyist mentality and they all want 100% of the data in RAM. When you are graphing a section of a database that could have a trillion rows that occupies a 20TB hard drive this is not possible. We need a database aware graphing package that operates on a cursor to create things like these.
Our graphing package needs to know how to use a database, have a timer for refresh, repaint only the necessary stuff, obtain its limits via separate SQL/Database I/O (for NoSQL databases or indexed files). For graphs like the above we probably need 3D support. We do not want a train wreck like Qt has for 3D support. This graphing portion of the library needs to support creating every graph in the following images without the user having to create custom code.
They should be able to configure color, shape, etc. Even the graph for the battery indicator and the vertical bar for SpO2 should be doable from the graphing classes without having to hand create a custom object.
Graphing classes need to be live-stream aware as well as database aware. When source is live-stream the amount of history kept in RAM must be configurable. It should also allow for a hook to call a storage routine for whatever the storage may be. When graphing medical data it is important to graph then record. If the store isn't internal to the device there can be a delay and if a patient is coding that can lead to a medical error with "adverse outcome."
Thankfully SDL3 includes CategoryGPU providing both 3d graphics and GPU computing.