3 ms·

Oh, I would love it if Wayland provided a standard UI toolkit (server-side)! Is that a thing that happened when I wasn't looking?

king_geedorah 1y ago
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. Edit: s/protocol/interface
- account42 1y ago
  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.
Cloudef 1y ago
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.
antihero 1y ago
How would this work given that the major DE's have completely different UX and design?
- AndyKelley 1y ago
  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.
  - antihero 1y ago
    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.
  - jon-wood 1y ago
    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.
    - AndyKelley 1y ago
      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.
      - codethief 1y ago
        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.
flohofwoe 1y ago
I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;) (yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)
- account42 1y ago
  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.
  - flohofwoe 1y ago
    > 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.

king_geedorah 1y ago

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. Edit: s/protocol/interface

account42 1y ago
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.

Cloudef 1y ago

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.

antihero 1y ago

How would this work given that the major DE's have completely different UX and design?

AndyKelley 1y ago
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.
- antihero 1y ago
  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.
- jon-wood 1y ago
  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.
  - AndyKelley 1y ago
    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.
    - codethief 1y ago
      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.

flohofwoe 1y ago

I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;) (yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)

account42 1y ago
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.
- flohofwoe 1y ago
  > 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.