While pulling in a library just for window decorations is insane, the same could make sense for a full UI toolkit - after all, that's how standard UI components have worked on e.g. Windows. In a way, Qt can already fulfill that role because by default it tries to adapt to the look and feel of the platform it runs on, including using GTK themes. Too bad that it's a bloated pig without a stable ABI that would allow you to use the system version.
> after all, that's how standard UI components have worked on e.g. Windows
Standard UI components on Windows are in user32.dll, and that's guaranteed to exist on each Windows installation all the way back to Windows NT.
And to just get an empty decorated window all I need to do is call CreateWindowEx() (which will always look consistent), all the rendering inside that window can then be done through one of the 3D APIs.
Same on macOS, I don't need any optional dependencies to create a decorated empty window which I can then render into with Metal.
For that same scenario (3D rendering into an empty window), Wayland only guarantees me a bare undecorated rectangle I can draw into with GL or Vulkan (and I wouldn't be surprised if even that is an optional feature I need to query first lol). And even if both GTK and Qt would be guaranteed to be installed on each Linux desktop system (so that I can pick one of two frameworks to give me a dedorated window, that would be overkill if I just want an empty window for 3D rendering - and even then I don't know if a window created through Qt would look consistent on a GNOME desktop or vice versa).
Of course that topic has been discussed to death without anybody who could fix that problem once and for all (by making the server-side decoration extension mandatory for desktop Linux systems) even recognizing that this is an issue that needs fixing.
Tbh, I don't even understand why desktop Linux needs more than a single Wayland implementation. So much wasted redundant work which could be put into actual improvements.
AFAIK, both KDE and GNOME had an architecture already where they changed only the base layer to adapt to wayland. Wlroot have a different architecture. And that’s why you have three mainstream implementations.
Slightly unrelated, but I wonder why the "Linux desktop maintainers" (whoever that is - and that this is even a question is probably the main problem) haven't come up yet with a minimal shared 'interface library' that's mandatory on each Linux desktop installation, and which provides a standard API (but no implementation) to create a window, get input events and probably also a set of simple UI widgets (buttons, sliders, checkboxes, lists - basically what Win32 or X11 provides).
KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.
Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.
Call it Common Desktop Environment or something idk...
I’m not a maintainer, but IMO, it may be the different design systems. Yes there are common elements like buttons and scrolled view. But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
> But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week.
A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Qt - and not just for the window chrome) - even if it only offers a common subset of GTK vs Qt vs ... features.
Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are.
...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications?
Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.
Yes, but Linux is only the kernel, everything else is someone else project. A distribution is nothing else than a curated list of software projects.
macOS is a good example of what you're proposing. The developer toolkit have a lot of nice frameworks (libraries) to help build apps. But that ties you to Apple. You can't expect consistencies across OS unless someone does the work to provide an intermediate layer, and then you loose on each OS nicest capabilities.
It may not make business sense, but the most elegant solution is to have a core that is your feature set, and then flesh out each dependency according to the platform.
