41–50 of 228 posts
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.
Earlier quoted context omitted.
[flagged]
The Wayland standard does not prescribe it (unlike X), and the reference implementations were monolithic for a very long time. Wayland in general had a rather cavalier approach to doing away with things that X users take for granted, like, well, making screenshots. Eventually, under pressure, those in charge agreed that these features are actually very important for real users, so implementations appeared. It's an un…
Indeed - implementations, plural. Incompatible with each other, naturally.
Earlier quoted context omitted.
You can do that already with libraries such as wlroots or Smithay
That's not the same thing. It's way easier to write an X11 window manager than to write a Wayland compositor, even with something like wlroots, because the window manager can speak the same protocol that clients speak, and it runs as a separate process. As a concrete example, Emacs' EXWM package works by implementing an X11 client library in Emacs Lisp, then using it to talk to the X server (which is a separate proce…
So it is architecturally possible (but infeasible in plain Emacs Lisp).
For river (the thing this article is about) I wrote an Emacs WM, but also opted for a dynamic module for the Wayland protocol parts: https://code.tvl.fyi/tree/tools/emacs-pkgs/reka
This one could technically be written in plain Emacs Lisp, but I'm happy to use something that already has all the XML codegen stuff for Wayland figured out. Dynamic modules work pretty well, fwiw.
> 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.)
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.
BSP?
Earlier quoted context omitted.
[flagged]
" Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." " https://news.ycombinator.com/newsguidelines.html
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.
There's a type of input called "DeviceEvent" which is a bit lower level than "Window event". It also occurs even if the window isn't "active".
Windows and X11 support this, but Wayland doesn't except for mouse movement. I noticed my program stopped working on Linux after I updated it. Ended up switching to Window Events, but still kind of irritating.
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.
You only need a single implementation that exposes an API for running a WM as an extension. I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.
Earlier quoted context omitted.
> I can make it do basically anything I want X11 can't do high refresh rates every time that I've tried to do so.
It runs just fine at 165 hz for me. Given that xrandr and CRTs have been around for a while, and both have supported high refresh rates for a long while, something seems fishy here. Something is probably at fault, but it's not X11.