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.
No, there are no protocols intended to implement such a thing at this time. I'm not aware of anybody attempting to spec out such a protocol either, but I do think it's a really interesting idea.
There is about zero chance that Gnome would implement such a protocol which makes the whole endeavor pointless. They can't even agree on server side window decorations.
That's precisely the point! It would be really nice for applications to be able to operate agnostic from the DE's decisions about UX and design. Applications want something much more high level: button here, scroll bar there, text input here. It's the DE's job to make such things accessible and look pretty. If you think about it, that's precisely why the web is a popular user interface target: the application has a much higher level interface, and all those concerns are, correctly, handled at a different abstraction layer.
I don’t think it’s possible to build a generic UI across DEs, at least if you actually want them to feel native. They’ve all got different standards, so while Gnome might have a button here, a text box here, and scroll bar there on KDE a scroll bar here, text box here, and then the button might make more sense.
My point is that the application doesn't have to care if it's running in Gnome or KDE. It just speaks Wayland protocol and then it gets a Window and some UI in it. The gnome window manager / KDE window manager then makes that UI properly native.
Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive events when the text in the box changes. The fact that I'm typing Japanese into a fancy UI shouldn't make any difference to the application, other than what text it receives from the widget events.
And that should all be possible in a small, static executable, that is speaking the Wayland protocol, and has zero dependencies other than networking syscalls.
I like the idea but, having built many UIs for many different applications over the years, I doubt it would work for anything non-trivial. The thing is, as soon as your UI reaches a certain level of complexity you need tight control over the look and feel, especially over the positioning of UI components relative to each other. Unfortunately, the latter depends a lot on how exactly your UI components look and behave.
For example, your text input box's label might be displayed to the left of the box, to the top, or it might be one of those floating labels that are displayed inside the box but move to the top border as soon as you focus the box. Depending on that, you would choose the spacing to neighboring text boxes and buttons differently, and maybe also arrange things differently altogether, because of different space requirements.
In other words: Your application would need to know what exactly the Wayland "UI layer" is going to display in order to send it precise instructions. But then your abstraction is very leaky.
No it is the developer's job to make things be nice and work well. We've gone past pretending to be native shit for pretty much everything. We define our own design styles and language since the web took off.
Server side ui toolkit doesnt make much sense to me. Better idea is to target some multimedia layer like web browser, electron, etc ... Or just hope someone someday comes up with UI library that doesnt suck.
