61–70 of 228 posts
If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
Earlier quoted context omitted.
When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
Earlier quoted context omitted.
When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol.
Separate process means that the window manager can be written in any language (even, e.g.: Python).
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.
The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life.
To this day, I still have different monitors with different scale factors.
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 not 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!
Earlier quoted context omitted.
Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
> It seems like instead of introducing another IPC protocol like this project does It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol. Separate process means that the window manager can be written in any language (even, e.g.: Python).
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.
Granted, my requirements were simple, a laptop and occasionally one external monitor, though the issues I did run into were related to graphics drivers and NVIDIA shenanigans, but not to X11.
Now that I'm on Wayland, I do feel that visuals are slightly more responsive and crisper, but honestly, it wasn't worth replacing a bunch of my programs, significantly altering my workflow, and dealing with numerous new issues I didn't have to deal with before.
Unfortunately, the momentum is now fully with Wayland, and it's only a matter of time until X11 stops being supported altogether. The XLibre project is a noble idea, but a few contributors can't maintain an entire ecosystem on their own.
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.
My reason for switching from i3 to sway (about 8 years ago) is DPI support. High DPI is a pain in Xorg, and essentially impossible with heterogeneous monitors. The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life. To this day, I still have different monitors with different scale factors.
I haven't touched xorg.conf in decades. I suppose you might have to do it to configure some unique setup, but for me this hasn't been an issue in a long time.
Now with Wayland, instead of having to touch a single config file, we have to learn how each compositor/WM is configured, and do it there instead. It hardly seems like an improvement in that regard, IMO.