6 ms·

> A unified way to change applications settings. This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings > becaus

by nialv7 6y ago

> A unified way to change applications settings. This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings > because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots. So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? > A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. I don't get this point. You can still use Cairo or similar graphic libraries on wayland too.

rnhmjoj 6y ago
> This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings That's why I said Wayland and the modern desktop in general. > So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X server. If I'm sloppy and my wm dies, it's not going to take down the whole desktop with it, contrary to a Wayland compositor. > A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. Of course, but the rendering happens on the client (with client-side fonts, images, etc.) instead of the server, which makes the protocol use a lot of bandwidth.
- sergeykish 6y ago
  Just think for a minute, entire industry abandoned xrdb and drawing primitives in X11 applications, even XOrg developers decided to ditch these features, they've started Wayland because they could not fix X11. Either you are unbelievably smarter or you know nothing.
  - rnhmjoj 6y ago
    Maybe I know nothing, but it quite common that the technically superior solution don't get a lot of adoption and eventually dies.
- nialv7 6y ago
  > which makes the protocol use a lot of bandwidth. not true in most of the use cases. ownership of bitmaps are transfered, no actual pixels are being copied.
  - rnhmjoj 6y ago
    Sure, locally: I had a remote display in mind.
zajio1am 6y ago
> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case. In the X11 case, relations are: wm - user - X11 (Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.) In the Wayland case, the relations are: user - wm/compositor - wl_roots (Users choose wm, wm developers choose to use wl_roots to implement wm features instead of doing it themselves, but that is just internal implementation issue of that wm and wm developers are responsible for wm behavior/bugs including ones inherited from wl_roots.)
- samus 6y ago
  That's actually a good thing! If the bug is in X, then the WM developers are powerless against it. If it is in wlroots, then something can be done about it. Since it's a library, it should be possible to roll out a bugfix at a faster pace than the X server. Worst case you fork and bundle wlroots, leave behind a pull request to the main project, and move on.

by nialv7 6y ago

rnhmjoj 6y ago

> This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings That's why I said Wayland and the modern desktop in general. > So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X server. If I'm sloppy and my wm dies, it's not going to take down the whole desktop with it, contrary to a Wayland compositor. > A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. Of course, but the rendering happens on the client (with client-side fonts, images, etc.) instead of the server, which makes the protocol use a lot of bandwidth.

sergeykish 6y ago
Just think for a minute, entire industry abandoned xrdb and drawing primitives in X11 applications, even XOrg developers decided to ditch these features, they've started Wayland because they could not fix X11. Either you are unbelievably smarter or you know nothing.
- rnhmjoj 6y ago
  Maybe I know nothing, but it quite common that the technically superior solution don't get a lot of adoption and eventually dies.
nialv7 6y ago
> which makes the protocol use a lot of bandwidth. not true in most of the use cases. ownership of bitmaps are transfered, no actual pixels are being copied.
- rnhmjoj 6y ago
  Sure, locally: I had a remote display in mind.

zajio1am 6y ago

> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing? There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case. In the X11 case, relations are: wm - user - X11 (Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.) In the Wayland case, the relations are: user - wm/compositor - wl_roots (Users choose wm, wm developers choose to use wl_roots to implement wm features instead of doing it themselves, but that is just internal implementation issue of that wm and wm developers are responsible for wm behavior/bugs including ones inherited from wl_roots.)

samus 6y ago
That's actually a good thing! If the bug is in X, then the WM developers are powerless against it. If it is in wlroots, then something can be done about it. Since it's a library, it should be possible to roll out a bugfix at a faster pace than the X server. Worst case you fork and bundle wlroots, leave behind a pull request to the main project, and move on.