Not a snowball's chance in hell of doing a Wayland compositor in 50 lines. OP has the benefit of the X server doing most of the work. Wayland compositors also have to do all of the rendering, input dispatching, GPU setup, etc themselves. With wlroots you could probably get pretty small, though, but you still have to do rendering et al yourself: https://github.com/swaywm/wlroots (note: I am the maintainer of this software)
I tried reading the source code for wlroot, and Sway, to figure out how hard it would be to base a "non tiling" window manager of it. It's very readable in isolation, but I struggled figuring out how stuff fits together. Maybe the issue is my limited understanding of C.
Do you have any pointers to getting started developing for with Wayland (and wlroot)?
I'll take your word for it, given who you are :)
50 lines wasn't really a hard requirement though, just minimal enough that you can sort of get a feel for the absolute basics. like equivalent capabilities to TinyWM. Sway doesn't quite fit that bill as it's more of a fully-fledged wm that you could install on machines you actually use for stuff (I'm running it on this machine for example)
ps. Thanks for creating/maintaining Sway! it's great stuff! ds.
Very cool :) On that note, I think it is great how much effort you put into making wlroots, sway and wayland accessible through your blogposts and the open development process.
While I have been busy and will be busy for a few more months I look very much forward to working through your posts and learning something about wayland and sway then :)
>> With wlroots you could probably get pretty small, though, but you still have to do rendering et al yourself...
Well yes and no. A wayland compositor has to blit the images of the applications which need to draw themselves into buffers. At least that's my understanding of it. The compositor isn't supposed to draw anything, it just copies things to the frame buffer. I would hope a basic compositor could be done with not too much code.
Blitting and rendering aren't too different. Blitting is pretty inefficient, too, particularly because many Wayland clients render on the GPU and give you an opaque handle to GPU resources so you don't have to copy pixels at all. And you can blit instead of using OpenGL or if you want, but it's still your job to do so on Wayland whereas on X the X server is doing it for you. You also still need to handle input, focus, multihead, etc all yourself.
>> some of us thinks that server side decorations are better for security, because otherwise a client can fake the look of another client.
If the decorations are done server-side then all applications will look the same anyway.
Having said that, I think decorations probably are the job of the desktop environment since those are the things that a user manipulates at that level of abstraction. Moving, resizing, closing programs is a UI thing and an application really shouldn't know where it is within the desktop environment. That's actually a security concern IMHO.
Would something like a middle-ware server work here? Something that handles all the backend stuff like the X-server does and provides a simple protocol that window managers could use instead of directly talking the wayland protocol? Basically wlroots as a daemon/service instead of a library.
The X protocol is Legacy Cruft and as such needs to be burned and the ashes sealed within a concrete block and buried at sea.
The whole point behind Wayland is to make a 100% clean break from X. Of course as it turns out that means reinventing and replacing all the things that made X good in the first place with something completely new, because newer=gooder. And reading old code is hard, so everything on the Linux tech stack needs to be completely reimplemented so GNOME devs can maintain it for its five-year lifecycle before it all gets thrown out and replaced with something even newer (and gooder).
How much of wlroots is devoted to dealing with the Wayland protocol, versus rendering and input handling?
Writing a heavily constrained, low-level compositor seems like an interesting project. Maybe something that only supports a single type of graphics output, and uses KMS and DRI directly.
