Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
"some of the most complicate aspects of software engineering is how to interface your work with the work of others"
And where exactly is the difference, when you write a OS, where you have to interface with the low level hardware and the choices of those engeneers?
Apart from that, what is stopping you? Just pick a simple plattform and start. But yes, the result probably will be hard to sell.
Alternativly, you can join SerenetyOS, which started exactly as just a one man project and came quite far alone. And now they are getting momentum (100000$ donation to build a browser).
https://serenityos.org/
For a recent project I chose Yue (https://libyue.com/), a cross-platform native widget GUI toolkit with C++, JavaScript/Node.js, and Lua. I've only used the Lua interface and macOS backend, but it has worked quite well, despite the very steep learning curve. This was also my first desktop GUI app, so I had to learn many implicit concepts that weren't obvious from the otherwise extensive documentation.
Yue was also the only option that 1) supported macOS, 2) supported Lua, 3) was sufficiently comprehensive to build a non-toy GUI app, 4) and that I could integrate into my (static) build. I couldn't even get the wxWidgets Lua interfaces to compile, and Qt and Fltk had similar stories, whereas reverse-engineering the baroque Yue build (based on Google's internal build systems) was relatively simple. Yue had some sharp edges, but I was able to work around them whilst patiently waiting for patches and fixes upstream.
Immediate mode interfaces were a non-starter for me. For a non-trivial set of otherwise typical controls and window management you have to implement too much yourself, plus being non-native they not only felt wrong (which admittedly is somewhat subjective; the younger crowd seems to think non-native, immediate mode interfaces look more state-of-the-art), but lacked other interfaces for proper desktop integration, like theme change signaling (i.e. notification that a user switch between light and dark modes in the macOS system settings panel).
All-in-all I would highly recommend Yue.
These bullet points are exactly what I did in Sciter (https://sciter.com)
- Windowing
-- Tabs
-- Menus
-- Painting
-- Animation
-- Text
-The compositor
-Handling input
-- Pointer input
-- Keyboard input
- Accessibility
- Internationalization and localization
- Cross-platform APIs
- The web view
- Native look and feel
On top of that DOM and CSS implementations to achieve declarative UI. And JS as a languuage behind UI - declarative in some sense way of defining UI behavior.
For me it was the text issues that dulled my desire to keep working it. I was updating a Nim based immediate mode GUI called Fidget (https://github.com/treeform/fidget) and fixed a number of issues. It was fun getting 9-patch rectangles with corners working, etc.
I even implemented a fair subset of CSS grid:
parseGridTemplateRows gt, ["row1-start"] 25'pp \
( https://github.com/elcritch/cssgrid )
However, text input is hard and tedious! Then you ideally would need to handle the different keybindings for each OS. You also loose any plugins the OS'es provide. Not to mention the lack of accessibility.
I recall reading that browsers shim out to native OS text fields and wonder how that's done. It really seems like the best approach for small GUI libraries to enabled first class text input.