On Sat, 1 Jul 2017 19:51:59 -0400 Rendov Norra <tsobf...@gmail.com> wrote:
Hey Rendov, > Are there any XOrg implementations that aren't a pain to compile? like most legacy codebases, you end up with a difficult to compile chunk. Others might give you more insight in what to choose. > I've heard people complain about wayland but I haven't heard any good > reason as to why it's actually bad, so I'm considering just going with > that if it's less of a pain. Wayland in itself actually is a very nice protocol. However, you cannot do much with it alone, as the compositor and everything on top (input handling, clipboard, keyboard-layouts, ...) have to be done by hand. There is a reference implementation called Weston, but it contains everything but the kitchen sink and has "module support". Now, every time someone wants to make a new Wayland compositor, people tell them to just write a Weston plugin, which is a very sucky way of approaching this. A clean-slate implementation of dwm would approximately require around 6-8k SLOC for all the kitchen-sinking. There are some nice libraries provided by the wayland project, like libinput, however, the general ecosystem is very very scattered, especially with regard to what one or the other compositor supports. I like to compare it to the web actually. Wayland is just the HTTP protocol so to say, allowing communication between server and client. The website itself though is left as a liberty to the developer, with all problems attached. One might just implement it nicely, minimally, or make a big chunk of Javascript and other dynamic stuff. But while you can make very simple websites with relatively little HTML, you can imagine that even making a very simple compositor for Wayland requires you to pump out of a lot of kitchen-sink code. The fundamental problem is that the Wayland-developers just didn't have the 99% in mind and instead tried to make the protocol as general as possible. The way they did Wayland was kind of nice, but even it lacks some modern ideas which should've been implemented now that the entire windowing system is revamped anyway, and here I'm talking about color management, accessibility aspects and many other important things. If you depend on the reference implementation to get even trivial things done, there's something wrong. And if Wayland matures and people ask for these extra things like color management and the like, we will again have 10 different interfaces to do it, separately for every compositor there is. Compartimentalization is the biggest problem we face in OSS today. Wayland had the chance with a clean-table-approach to really make something great which unifies the Unix desktop in some way. Given there hasn't been much movement in this space in the last few years (I'd expect much more given how many problem X makes), I think X will stay with us for many more years. Tl,DR: Wayland is not the problem, but the fact that the Wayland developers were not brave enough to standardize some things built on top of it. With best regards Laslo Hunhold -- Laslo Hunhold <d...@frign.de>
