Hacker News new | ask | show | jobs
by nialv7 1925 days 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.

2 comments

> 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.)

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.
> 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.

> 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.

Sure, locally: I had a remote display in mind.
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.

Maybe I know nothing, but it quite common that the technically superior solution don't get a lot of adoption and eventually dies.