[rnhmjoj]

I think Wayland, and the modern desktop in general too, has forgot about a few good ideas that the original X system had. I will miss them once Wayland has taken over:

- A unified way to change applications settings. All old X apps used to read the X resources database (xrdb): you could set a global color scheme, fonts, window geometry and what not, all in one place using a simple but powerful text format.

- The simplicity of the window managers, hotkey daemons and other X clients. You can implement a functional wm in a few hundred lines of C[1] because the X server takes care of most of the stuff. In comparison a compositor has much more work to do and it's difficult to implement one, unless using a big library like wl_roots.

- A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. This would make writing a simple application without importing huge frameworks feasible again. Also sending the drawing calls over the network would probably be less bandwidth intensive.

[1]: https://github.com/vardy/aphelia

[nialv7]

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

[zajio1am]

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

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.

[rnhmjoj]

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

[nialv7]

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

Sure, locally: I had a remote display in mind.

[sergeykish]

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]

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

[sergeykish]

- I've never seen xrdb used outside of terminal configuration

- You have to link against X11, dwl (dwm for Wayland) implemented in 2500 LOC [1]

Plan 9 /dev/draw is simpler yet, somehow it was not reason against X11.

[1] https://github.com/djpohly/dwl

[rnhmjoj]

All the old X apps used xrdb, to some degree. I think of xclock, xbiff, xditview, xcalc, bitmap, etc.

[brmgb]

Everyone stopped using xrdb more than twenty years ago, same things for drawing primitives.

I understand the wish some seems to have for things to never change. It's probably very comforting but things have to move with their time or they will be left behind.

[rnhmjoj]

I'm not saying applications should continue to use or go back to xrdb. I'm pointing out the fact that having unified configuration system is very useful and I'm disappointed Wayland didn't pick up this idea.

[sergeykish]

Wayland reflects status quo. Truly desired missing features are reimplemented — screenshots, screensharing, networking. Try to make a change, maybe you'd find out this feature is not that useful.

I'd better think why .Xresources never catched up. For example, I've downloaded Gnome theme. It contains some CSS files, a lot of images and some rc files. Or check about:config, chrome://flags/ — no images there, but interface is so much nicer than a list in man pages and plain text editing.

[TacticalCoder]

> - I've never seen xrdb used outside of terminal configuration

Terminal and Emacs are the two I'm using it for.

[addicted]

> The simplicity of the window managers, hotkey daemons and other X clients. You can implement a functional wm in a few hundred lines of C[1] because the X server takes care of most of the stuff. In comparison a compositor has much more work to do and it's difficult to implement one, unless using a big library like wl_roots.

This sounds like they simply extracted some of the work X used to do into an external library. That sounds like an excellent choice with no particular downside IMO?

[yjftsjthsd-h]

Why is a library any better? Not even disagreeing; I can't see why to prefer either approach.

[forgotmypw17]

The beauty of free software is that X will always be there for anyone who wants it, just like you can still get great distros without systemd.