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.
While X is a giant program that offers a lot of features, Wayland is not a program but a protocol. Wayland composotors, implementations of Wayland protocol, are usually intertwined with their desktop environments. So I guess similar examples using Wayland are not as universal as using X and do not help much to learn about Wayland itself.
Still, there is a convenient Wayland compositor library that is designed for devs to build own window managers. Check wlc [1]. wlc has a nice and simple example [2] but not as short as TinyWM.
All the simple "window managers" for Wayland seems to be tiling for some weird reason. I think Wayland adoption could be higher is if there was a simple, easy to customize basic WM that people could fork to go do their own thing. I know Weston exists, and others, but if you look at how many X11 Window Managers that have been forked of AWM or EvilWM then perhaps Weston is a little to complex.
I think "some weird reason" is that the tiny minority of users who want a WM/compositor without a DE like Gnome or KDE have already opted for minimalism and are therefore predisposed toward tiling.
The traditional stacking methodology of managing windows is particularly poor. If you have 2 windows open anything will do but it becomes ungainly with more than a handful of windows open unless you spread your windows out among multiple spaces/workspaces/virtual desktops and on each one arrange and resize windows so you can see the windows you want to view together at once.
At that point you have recreated a normal efficient way to use a tiling window manager with the additional burden of doing the tiling yourself instead of having the wm do it for you.
It seems likely that those who have an enthusiasm for this workflow are mostly working on desktop environments like gnome/plasma/lxqt.
actually i like to have lots of partially overlapping windows. every window is exactly where I left it and the frequently touched ones will have a small bit visible that i can grab on to bring the whole window to the front. if i only care about part of a window, then i can efficiently arrange my windows so only the part i care about is visible (while still interacting with it since I have focus-follows-mouse).
it's far more useful than a taskbar or expose, since they keep moving what i'm using. the taskbar is a particularly poor design since all i have is a title and at that point i'm just guessing and hoping.
tiling window managers and raise-on-focus systems don't particularly appeal to me because they require me to see the whole of a window. tiling window managers probably have a way to ensure a window is exactly where i left it but it seems antithetical to the alleged advantages. (doesn't "automatically manage your windows" mean "automatically decide where to put a window, and move them around based on the size of other windows"?)
Some wm automatically arrange windows in a layout others example i3wm just split the screen between windows on a given screen/workspace.
Note that a workspace in this instance is only one monitor in a multi monitor configuration.
By default a single window workspace it takes up all the space. Opening another gives you a new window to the right of the first each half the width of the screen.
On a tall not wide screen it would appear below the first each half the height of the screen.
You can have splitv and splith containers as well as vertical or horizontal tabbed layouts of any kind of windows.
Dialog windows are automatically floating.
You can have containers by containers or nested as you please example 3 horizontal tabs each split in half if you like.
Any chance anyone knows of something similar to this but using Wayland as opposed to X?