HN

Comments (74)

• _flux
  To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment:> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing.(That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)
• kyorochan
  River was really great even before this split, so I'm very excited to see what happens in the space in the future. I switched to Niri while waiting for it to happen, and I'll probably switch back at some point.If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
• Menu

  oofbaroomf
  I'm currently using a fully vibe-coded, personal River window manager that works just how I want it to. I switched to it after I realized I couldn't do everything I wanted in Hyprland (e.g. tile windows to equal areas instead of BSP by default).Simple example of how impactful this separation has been for me.
• Menu

  asveikau
  The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.
• Menu

  csb6
  Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.
• hparadiz
  Lots of weird misinformation in the comments here. Wayland doesn't choose anything. It leaves the compositor to decide where to position a window and whether or not that window receives key presses or not. The program can't draw wherever it wants or receive system wide keystrokes or on behalf of another program. When appropriately implemented the screenshot system is built directly into the compositor. It's an API that let's a program request read access to a part of the screen and the compositor provides upon approval. It's much more secure that way and it works perfectly fine these days. Unfortunately not every compositor implements this.However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keydA project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want.And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.
• Menu

  wild_egg
  I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple.Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.
• Menu

  sourcegrift
  At this point, take all the lessons of wayland, plan everything in advance rather than incrementally deciding basic things like screenshotting and then build something new, superseding wayland so that power users like me and app developers will stop clinging to X. Right now I have no confidence in wayland and I know I'm not alone.
• SilentM68
  Insightful article. I don't recall ever viewing an easy-to-follow lesson, tutorial or book for that matter that clearly explained the various components of a Linux Desktop environment. Always had to follow complicated and obscure guides to do this and that, when solving issues, but seldom did any explain their functions clearly.
• Menu

  mikkupikku
  If Wayland doesn't get this solved then I'll just use X11 forever, with coding agents to keep it running if I have to.
• Lerc
  So that's a Wayland ex-window manager then?
• Menu

  jauntywundrkind
  super interested to hear more on this.i'm a little thrown, because the Wayland diagram doesn't feel quite right. the compositor does lie between the kernel and the apps, but IIRC the apps have their own graphics buffers from the kernel that they are drawing into directly. the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor is between the kernel and the output / input.i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).it means that the task of writing the display-server / compositor is much much much simpler. it's still hard! but the kernel is helping so much. there's an assumed base of having working GPU drivers!author appears to super know their stuff. alas the FOSDEM video they link to is not loading for me. :(one major question, since this is a protocol, how viable is it to decompose the window management tasks? rather than have a monolithic window manager, does this facilitate multiple different programs working together to run a desktop? not entirely sure the use case, but a more pluggable desktop would be interesting!
• imiric
  I'm very excited about river.I switched to niri a few months ago, and while I like it for the most part, it feels too... busy for my taste. It defaults to a bunch of animations and decorations, all of which I've turned off. I'm happy with my current setup (aside from Wayland quirks[1]), but river's design and simplicity are very appealing. It reminds me of the philosophy of bspwm/sxhkd which I used for years on X11.I do need scrollable tiling now that I've tried it, and I'm happy that there are a couple of options to choose from with river.[1]: Seriously, why does copy/pasting sometimes simply doesn't work?? I often have to copy twice for it to succeed. It's not related to Xwayland -> Wayland apps, and viceversa, or with copying from closed windows, etc. I don't use nor want a clipboard "manager". I just want my clipboard to work consistently. I've read many reports of this same bug on different distros and DEs, and nobody has figured it out. It's infuriating that such a basic feature is half-broken in a project that is 17 years old now!
• Babkock
  [dead]
• Menu

  davispeck
  This is a really interesting direction.Separating the compositor and window manager feels like one of those ideas that seems obvious in hindsight, but the protocol/state-machine design here shows why it took real work to make it practical.Lowering the barrier for writing Wayland window managers without forcing everyone to build a full compositor seems like a big win.