4 ms·

A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.

sprash 7y ago
That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality. This is especially true for people that prefer low latency over tear-free rendering.
- majewsky 7y ago
  I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic. Now, people complain about there being competing Wayland implementations with different feature sets. What's it gonna be, guys?
  - simion314 7y ago
    >I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic ? what? you mixed systemd with wayland maybe, everyone knows that wayland is a protocol, this is repeated 100 times in each thread , everyone also knows that most of X features are not part of wayland
  - nshepperd 7y ago
    Those complaints aren't actually opposed but perfectly complement each other. Wayland requires* everything to be monolithically built into the display server (which is also the window manager), which means if I want to use a new WM (say, XMonad) I need to reimplement all of this stuff. Want screenshots? Build it into your WM! Want redshift? Build it into your WM! The result is that development effort will be wasted reimplementing "competing Wayland implementations" stuff that no-one actually wants. Compare X11, where I could run an Xorg server together with any of a number of lightweight window managers, and the window manager is only responsible for, y'know, managing windows, and determining how the window decorations look. Xorg handles everything else, allowing a robust marketplace of competing WMs to arise. * Unless/until they finally give in and standardise protocol extensions for out of process window managers.
makomk 7y ago
I don't think any of those problems can be solved solely in the compositor - they all require co-operation between it and the actual apps. Which means, in practice, that you'd probably have to create an entirely new version of the Wayland API for creating and managing windows, add it to all the compositors, and get all the apps to use it too, on top of all the other work involved in fixing those issues. (This is the only real way to extend the protocol and has already been done a few times - the most recent one I remember was to add the ability to minimize windows.)

That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality. This is especially true for people that prefer low latency over tear-free rendering.

majewsky 7y ago
I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic. Now, people complain about there being competing Wayland implementations with different feature sets. What's it gonna be, guys?
- simion314 7y ago
  >I don't get this thread. On one hand, people complain (wrongly) about Wayland being too monolithic ? what? you mixed systemd with wayland maybe, everyone knows that wayland is a protocol, this is repeated 100 times in each thread , everyone also knows that most of X features are not part of wayland
- nshepperd 7y ago
  Those complaints aren't actually opposed but perfectly complement each other. Wayland requires* everything to be monolithically built into the display server (which is also the window manager), which means if I want to use a new WM (say, XMonad) I need to reimplement all of this stuff. Want screenshots? Build it into your WM! Want redshift? Build it into your WM! The result is that development effort will be wasted reimplementing "competing Wayland implementations" stuff that no-one actually wants. Compare X11, where I could run an Xorg server together with any of a number of lightweight window managers, and the window manager is only responsible for, y'know, managing windows, and determining how the window decorations look. Xorg handles everything else, allowing a robust marketplace of competing WMs to arise. * Unless/until they finally give in and standardise protocol extensions for out of process window managers.

makomk 7y ago

I don't think any of those problems can be solved solely in the compositor - they all require co-operation between it and the actual apps. Which means, in practice, that you'd probably have to create an entirely new version of the Wayland API for creating and managing windows, add it to all the compositors, and get all the apps to use it too, on top of all the other work involved in fixing those issues. (This is the only real way to extend the protocol and has already been done a few times - the most recent one I remember was to add the ability to minimize windows.)