4 ms·

Could we please have a comment about why this is an X11 WM rather than a Wayland compositor? Technical issues or a stylistic choice?

by roenxi 3y ago

deleted 3y ago
[deleted]
p_l 3y ago
Outside of any personal preferences of author, Wayland compositors are just more complex. Even with availability of libraries like wlroots. After all, a Wayland WM is not just a WM, it also has to run and handle display server including talking with HW if you want any sensible performance.
- kaba0 3y ago
  Because a window manager on X is roughly the equivalent of a Gnome extension. That’s just a design question where we draw boundaries.
vidarh 3y ago
It's an interesting question... Writing a Wayland compositor from scratch means writing the whole display server. Wlroots readme describes it as "about 60,000 lines of code you were going to write anyway". For comparison my wm is <1k lines. So they're not equivalent - writing a Wayland compositor from scratch is more like writing the whole X server first, before even starting the WM. I could use wlroots or another compositor as a starting point. I did look at it, but I'm still on X, and have no compelling reason to switch. Yet, anyway, and that adds to the "cost" for me in terms of disruption. Where I could translate TinyWM into a few dozen lines of Ruby in a couple of hours and switch to actually using it and build from there, and "just" suffer some nuisance that I can slowly chip away at when I have time, even getting a basic wlroots binding + minimal compositor running seemed like a far more complex project. I'm itching to figure out how to eat my way further down the stack, but I can't justify spending time on it unless I see a viable way of doing it (relatively) piecemeal. E.g. I can restart my wm without exiting my X session, and so without losing any open applications. That gets far more disruptive for replacing the X server (whether by another X server or a Wayland compositor), and also allows for a far faster cycle - I can spot a problem, fix it, restart the WM and keep working without having to close everything... I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X.
- yxhuvud 3y ago
  > I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X. Isn't that already the case, by protocol definition? At least compositor and clients talk to each other over a pipe of some sort. It is actually a bit problematic because the way it is done put noticeable restrictions on both sides on processing things in time, because if it is full then shit hit the fan.
  - vidarh 3y ago
    Not in Wayland, no. The only boundary is between the client and compositor. With X there is a boundary between the client and server, and between the server, wm, and compositor. With Wayland the compositor serves the same function as both the X server, wm, and compositor in one. There's nothing inherent stopping the addition of extensions to allow the same split as in X (but the server/compositor split probably wouldn't be worth keeping - the WM is easier to split out because it's far less latency sensitive)
    - kaba0 3y ago
      That’s not true in this respect. This all is just an implementation detail, not mandated one way or another by Wayland.
      - vidarh 3y ago
        While it's not mandated, as I pointed out ("There's nothing inherent stopping the addition of extensions to allow the same split as in X"), I'm not aware of a single Wayland compositor for which it isn't true. If there is one, I'd love to hear about it.
- markstos 3y ago
  TinyWM for wlroots is also less than 1,000 LoC. ( https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.c https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.... ) > I can restart my wm without exiting my X session Sway also has a "reload" feature that preserves all open applications.

Could we please have a comment about why this is an X11 WM rather than a Wayland compositor? Technical issues or a stylistic choice?

by roenxi 3y ago

Could we please have a comment about why this is an X11 WM rather than a Wayland compositor? Technical issues or a stylistic choice?

deleted 3y ago

[deleted]

p_l 3y ago

Outside of any personal preferences of author, Wayland compositors are just more complex. Even with availability of libraries like wlroots. After all, a Wayland WM is not just a WM, it also has to run and handle display server including talking with HW if you want any sensible performance.

kaba0 3y ago
Because a window manager on X is roughly the equivalent of a Gnome extension. That’s just a design question where we draw boundaries.

vidarh 3y ago

It's an interesting question... Writing a Wayland compositor from scratch means writing the whole display server. Wlroots readme describes it as "about 60,000 lines of code you were going to write anyway". For comparison my wm is <1k lines. So they're not equivalent - writing a Wayland compositor from scratch is more like writing the whole X server first, before even starting the WM. I could use wlroots or another compositor as a starting point. I did look at it, but I'm still on X, and have no compelling reason to switch. Yet, anyway, and that adds to the "cost" for me in terms of disruption. Where I could translate TinyWM into a few dozen lines of Ruby in a couple of hours and switch to actually using it and build from there, and "just" suffer some nuisance that I can slowly chip away at when I have time, even getting a basic wlroots binding + minimal compositor running seemed like a far more complex project. I'm itching to figure out how to eat my way further down the stack, but I can't justify spending time on it unless I see a viable way of doing it (relatively) piecemeal. E.g. I can restart my wm without exiting my X session, and so without losing any open applications. That gets far more disruptive for replacing the X server (whether by another X server or a Wayland compositor), and also allows for a far faster cycle - I can spot a problem, fix it, restart the WM and keep working without having to close everything... I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X.

yxhuvud 3y ago
> I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X. Isn't that already the case, by protocol definition? At least compositor and clients talk to each other over a pipe of some sort. It is actually a bit problematic because the way it is done put noticeable restrictions on both sides on processing things in time, because if it is full then shit hit the fan.
- vidarh 3y ago
  Not in Wayland, no. The only boundary is between the client and compositor. With X there is a boundary between the client and server, and between the server, wm, and compositor. With Wayland the compositor serves the same function as both the X server, wm, and compositor in one. There's nothing inherent stopping the addition of extensions to allow the same split as in X (but the server/compositor split probably wouldn't be worth keeping - the WM is easier to split out because it's far less latency sensitive)
  - kaba0 3y ago
    That’s not true in this respect. This all is just an implementation detail, not mandated one way or another by Wayland.
    - vidarh 3y ago
      While it's not mandated, as I pointed out ("There's nothing inherent stopping the addition of extensions to allow the same split as in X"), I'm not aware of a single Wayland compositor for which it isn't true. If there is one, I'd love to hear about it.
markstos 3y ago
TinyWM for wlroots is also less than 1,000 LoC. ( https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.c https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.... ) > I can restart my wm without exiting my X session Sway also has a "reload" feature that preserves all open applications.