Earlier quoted context omitted.
You could use xlibre, although some people say it's a joke
Just use Xenocara and stop reusing LLM slopware.
Does Xenocara run on anything other than OpenBSD?
Separating the Wayland compositor and window manager
101–110 of 228 posts
Re: Separating the Wayland compositor and window manager
#102As predicted, we will re-invent X11 one feature at a time. Maybe someday soon a Wayland window will be able to know its own screen position.
Re: Separating the Wayland compositor and window manager
#103Wasn'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.
[deleted]
Re: Separating the Wayland compositor and window manager
#104I'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.
Sway is basically i3 on Wayland. You pretty much keep your config file (with a few modifications), there really isn’t much friction. That’s not a reason to do it of course, for me the driver was support for multiple monitors with different scaling requirements.
Sort of. If your software wants to do something like "know where the pointer is" it won't work on sway.
Re: Separating the Wayland compositor and window manager
#105To 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…
X11 has some tricky, imposible to fix (within the confines of the existing protoco) issues because of the seperation between Xserver and window manager. Things like (IIRC) initial window placement and what nots, where ideally the window manager would make choices about things before the process continues, but the reality of distributed systems makes everything hard. Combining some things into an integrated process fixes that, but comes with other issues.
There were probably other ways to fix those issues, but it would still be a fair amount of churn.
Re: Separating the Wayland compositor and window manager
#106Well, it only took 15 years to someone to fix one of many Wayland design flaws and start to make it feel usable.
Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers.
Then, people who think they know better than everyone else will throw Wayland away and start from zero all over again.
Re: Separating the Wayland compositor and window manager
#107[flagged]
Re: Separating the Wayland compositor and window manager
#108As predicted, we will re-invent X11 one feature at a time. Maybe someday soon a Wayland window will be able to know its own screen position.
Last I checked the idealists weren't even willing to commit to a virtual 2D rectangular grid of pixels of arbitrary width and height. I think we'll be waiting a while (or more likely using a soft fork of the spec).
Re: Separating the Wayland compositor and window manager
#109I'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 hoop I recently jumped through: 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.
Isn't being able to read input while unfocused a huge security issue?
Meanwhile if you have root you're still free to do so directly.
Re: Separating the Wayland compositor and window manager
#110[flagged]
I feel like the word "protocol" is tripping you up. This isn't meant to be some standard that gets a bunch of traction in other projects. It's a protocol for the the River compositor; as the name suggests. Before this there was, I believe, river-layout-v3. It's all just getting taken to the next level; from layout to full window management.