Note: As there's no "official" GUI library for Linux, GTK 3 has been chosen as it is the one that works and can be configured on the most distros. It's also the reason Libadwaita won't be adopted, as it's meant for GNOME and GNOME only by disallowing styling and integration with other DEs.
The never ending unsolvable problems, in-fighting and conflicts that keep plaguing the Linux Desktop has now spread onto aspiring cross-platform GUI libraries to make a compromise to avoid certain integration(s) with other libraries that will limit future functionality if someone decides to use it.
This is a solved issue for macOS and Windows, but never Desktop Linux which is a terrible shame for more than 20+ years.
Sadly Gtk developers were in a position during Gtk2's peak to help solve that by making Gtk2 "the" Unix desktop GUI API - it was used and targeted to by pretty much everything and it being a C API meant that it could remain backwards compatible for pretty much forever.
But they instead decided to break the API with Gtk3, repeating the Gtk1 to Gtk2 transition mistake (which at the time it wasn't that big of a deal since Gtk1.x was never as popular or widespread as Gtk2). And just as some projects finally managed to convert their Gtk2 code to Gtk3 code, sometimes after years of work, the Gtk developers awarded them for their effort by breaking the API again in Gtk4.
IMO at this point relying on anything Gtk4 is a mistake, though sadly there aren't many alternatives. Qt, being essentially a commercial middleware that also happens to have OSS-licensed code drops, has different priorities - and even if they wanted, being written in C++ which has no real stable ABI means they wouldn't be able to provide stable APIs anyway.
Other toolkits are asphyxiated by the oxygen that Gtk and Qt are siphoning away so they barely get any support. EFL seemed to be ok (in that it was a sort of usable, sort of existing, C-based API that is apparently good enough for a desktop environment to be made with) but the author seems to have decided at some point to refactor (and thus break) the entire thing. Motif has been stable since the 90s, but it also has seen little improvement since the 90s either - it is also too tied to X11, meaning that having a crossplatform version (which is something that people would want) is quite hard.
And thus we get Electron, which is almost a step before bundling an entire VM and OS inside a window.
For .NET based ones, WPF or if feeling adventurous since it is still in preview MAUI (which uses WinUI 3.0 + WinAppSDK on Windows).
WinAppSDK is the new name for Project Reunion.
UWP is supposed to be deprecated and on the way out, but given the slowness of WinUI 3.0 improvements, apparently even Microsoft teams are still using it, e.g. the new Windows 11 appstore.
For those using C++, on the MS GUI stack, as rediculous as it might seem, MFC is still the best they can do.
There was a short while where C++/CX seemed to be Microsoft catching up with C++ Builder in regards to RAD tooling for C++ developers on Windows, but C++/WinRT mutiny killed that dream.
So all things considered, Win32/MFC for C++ devs, Win32/WPF for .NET ones, unless feeling adventurous and not afraid of code rewrites.
Comments
Great library, however:
The never ending unsolvable problems, in-fighting and conflicts that keep plaguing the Linux Desktop has now spread onto aspiring cross-platform GUI libraries to make a compromise to avoid certain integration(s) with other libraries that will limit future functionality if someone decides to use it.
This is a solved issue for macOS and Windows, but never Desktop Linux which is a terrible shame for more than 20+ years.
Sadly Gtk developers were in a position during Gtk2's peak to help solve that by making Gtk2 "the" Unix desktop GUI API - it was used and targeted to by pretty much everything and it being a C API meant that it could remain backwards compatible for pretty much forever.
But they instead decided to break the API with Gtk3, repeating the Gtk1 to Gtk2 transition mistake (which at the time it wasn't that big of a deal since Gtk1.x was never as popular or widespread as Gtk2). And just as some projects finally managed to convert their Gtk2 code to Gtk3 code, sometimes after years of work, the Gtk developers awarded them for their effort by breaking the API again in Gtk4.
IMO at this point relying on anything Gtk4 is a mistake, though sadly there aren't many alternatives. Qt, being essentially a commercial middleware that also happens to have OSS-licensed code drops, has different priorities - and even if they wanted, being written in C++ which has no real stable ABI means they wouldn't be able to provide stable APIs anyway.
Other toolkits are asphyxiated by the oxygen that Gtk and Qt are siphoning away so they barely get any support. EFL seemed to be ok (in that it was a sort of usable, sort of existing, C-based API that is apparently good enough for a desktop environment to be made with) but the author seems to have decided at some point to refactor (and thus break) the entire thing. Motif has been stable since the 90s, but it also has seen little improvement since the 90s either - it is also too tied to X11, meaning that having a crossplatform version (which is something that people would want) is quite hard.
And thus we get Electron, which is almost a step before bundling an entire VM and OS inside a window.
For Windows? Should we target UWP or WinUI? WPF? WinForms? MAUI? Project Reunion? Or should we just stick with Win32? Maybe MFC.
Depends on the language.
For .NET based ones, WPF or if feeling adventurous since it is still in preview MAUI (which uses WinUI 3.0 + WinAppSDK on Windows).
WinAppSDK is the new name for Project Reunion.
UWP is supposed to be deprecated and on the way out, but given the slowness of WinUI 3.0 improvements, apparently even Microsoft teams are still using it, e.g. the new Windows 11 appstore.
For those using C++, on the MS GUI stack, as rediculous as it might seem, MFC is still the best they can do.
There was a short while where C++/CX seemed to be Microsoft catching up with C++ Builder in regards to RAD tooling for C++ developers on Windows, but C++/WinRT mutiny killed that dream.
So all things considered, Win32/MFC for C++ devs, Win32/WPF for .NET ones, unless feeling adventurous and not afraid of code rewrites.