GTK is always GNOME first and has issues most other places or just looks ugly.
wxWidgets always looked off and had the weirdes issues.
Qt (or at least QtWidgets) was fairly solid in design and implementation. Then they kind of put that on ice and started with a second GUI framework (QML) that didn't fit together whatsoever. Now it has a split personality and the widgets part has a hard time to keep up with modern problems like high-resolution screens and and scaling (I'm writing this from KDE, so I know first hand).
Then everyone tried to re-invent the user interface paradigm and that's how we ended up in the current mess. Consistent buttons, input boxes and frameworks were replaced by flashy but fairly unusable interfaces, which of course did not work out. So now we have this weird mix of not letting go and not knowing where to go.
You could go very old school though, with something like http://www.fox-toolkit.org or https://www.lazarus-ide.org/
wxWidgets?
For audio-related software (such as Helio Workstation[0]) there is JUCE.[1]
$ ./score-v3.0.0-a4-Linux.AppImage
Illegal instructionIt is a tough learning curve but I'm starting to see the light. Depending on your application, completely self-contained GUIs don't actually need that much code - it's mostly the knowledge of how to architect them.
A hard problem is how to approach construction of Widgets and hierarchies of control elements. The traditional OO centric approach is far too much boilerplate to be practical without a huge third-party library, but the Immediate GUI approach which got talked about a lot recently is maybe a little simplistic. I think I've found a good middle ground between "immediate" and "retained".
- it is capable of storing state: storing position in scroll view, which page is currently visible, etc. - it tracks dependencies, so ideally UI building code is executed again only if something changed that would affect it's output.
The important point is that I don't allocate and re-initialize the state of all controls. It's enough if you do from scratch the layout - that gets much simpler if you don't have to code a diff against the previous state.
So I basically have a simple Widget abstraction - a draw function and a process-input function + some identification data (implemented as a union of void-ptr and int). I can then make lists of these abstract Widgets, and each list represents the set of childs of a superordinate element.
This abstraction allows me to construct hierarchies and to have unabstracted and very flexible code for the layout, while the layout and input processing code can be generic - it's a simple loop over the list, calling the callback with the abstract handle.
If there are ever performance problems you can still fluidly move more towards some retained layout state. This for sure will require more complex code, but if you just do it for complex layouts with lots of elements, I figure you get the best of both worlds.
Mouse and drag handling is a little bit tricky as well - how to keep sending events to the slider control widget for example even if the mouse is temporarily outside the widget? The important realization is that dragging needs global state. You set the mouse globally as "grabbed" and provide a callback to execute when there are more mouse events.
I don't do Macs so far, so I can't tell you about that. I have a little boilerplate for setting up a window and getting input events for X11 (Linux) and Win32/GDI. It's about 300-400 lines each.
You can opt to use GLFW3 instead to target all the big platforms with a single file that is also 300-400 lines. Mac is supported, too. I have mostly ceased to use GLFW since I prefer to code the stuff myself to have absolute control in case I need it, and to understand the issues of the platforms I have dealt with - but frankly GLFW is a very good and sleek library to get an OpenGL window and some inputs.
Getting to the web using emscripten was similar. They support an older GLFW2 API so it was a matter of maybe 30 minutes to convert my GLFW code to run on the web. They also have a HTML5 API (html5.h) which is probably better, so I expect to add another couple hundred lines later at some point for that.
Emscripten / the Web required me to port my desktop OpenGL code to OpenGL ES 3.0, which was quickly done and a very good idea to do anyway.
And after all, the OpenGL rendering backend code is not that big either if your architecture is right. Mine is currently 700 lines, and it supports solid faces, textured faces, alpha-channels, subpixel font rendering - all of course for 2D and 3D.
Last time I had to do a gui, I chose JavaFX, and it was fine. But I’m still looking for native options, even if I have to implement the ui 3 times.
Edit: to clarify, I’m looking for something beyond C/C++
It you want to explore the Rust option, here is an overview of the status of GUI toolkits in Rust: https://areweguiyet.com/
Also - while a lot more low-level - Skia. Sublime Text/Merge and Aseprite are using it.
But show an app made with it to anybody below 30 and they will call you an ancient fossil.
If something doesn't have transition and gesture nowaday, you better market it to accountants because the general public won't want it.
Everything I do on a computer, apart from the odd movie I watch, is centered around information in text form, yet literally every program except decent text environments try their best to ruin working with text. The only place where I think a non-text-based ui actually adds something is in calendar applications, yet most of the suck as well.
So I sit here alone with the marvel that is 1980s technology, thinking most things regarded as "modern" in computing are a farce.
The only new general purpose tool I can stand is VSCode, where my o my critique is that it isn't emacs (and that multiple cursors are a decent but not a great replacement for macros)
http://fox-toolkit.org/screenshots/iims3.png
edit Too late I see skriticos2 already mentioned FOX.
You can use Gtk to make executables on Windows and MacOS, but it's not comfortable and the resulting guis are ugly. They do not take advantage of the full provisions of the platform. Gtk is less cross platform, and more a foundational Gnome library that someone has ported to Windows and MacOS. No support for two major operating systems.
Qt I can't speak to.
WxWidgets seems to be a little .. dated. The screenshots on their website look like programs that were acceptable for a technical user 15 years ago. Has it moved on from that? Dunno. No support for two major operating systems.