51–60 of 86 posts
Earlier quoted context omitted.
It already exists and its called xwayland. Most wayland compositors also have X11 WM inside them...
You misunderstand: I'm not talking about the X protocol, I'm talking about some new all Wayland thing just so window managers can be separated from the other things you'd otherwise have to implement.
Any advantages over Sway, other than look and feel?
That alone is interesting enough to get me to look at switching..
The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. This in…
There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time. [0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available.…
The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. This in…
There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time. [0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available.…
And because screenshots are a privileged operation, this will always need to go through a back-channel anyway to handle the security aspect. Otherwise you'll end up with a repeat of X11 again where any Wayland client connected to the server can scrape the screen at all times. So for desktop use there's really no reason to ever put it in a Wayland protocol. The design from the beginning was to keep privileged operations (like screenshots and input grabs) out and that still holds true now.
The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. This in…
Shoutout for Cardboard, an awesome Wayland compositor and a rare example of Scrolling Tiling window management.
I'd love to take advantage of this incredible tool in MacOS. Managing windows on MacOS is quite a challenge.
I sorely miss tiling WMs when I use MacOS; Amethyst and yabai just seem to big out all the time, lose track of windows, get confused by native tabs, and deal poorly with windows that force maximum/minimum sizes. I've concluded that MacOS's window model just really doesn't mesh with tiling. My current solution, after much experimentation with tools like Rectangle, Hookshot, and Spectacle, is to use Swish[1]. It feels…
However I'm not sure Swish solves the big benefit of i3/bspwm for me, which is the lightning-quick virtual desktop and "send to desktop" functionality of a tiling WM on linux. Having two apps open side by side is useful, but not quite as useful as having two apps open full screen on virtual desktops 1 and 2, and the switch between them being totally instantaneous.
I want to switch, but it's still super glitchy on NVIDIA and waaay too slow on my laptop.
Earlier quoted context omitted.
There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time. [0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available.…
No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns. And because screenshots are a privileged…
There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. If someone wants to "install Wayland", technically they might end up having to research which framework they have to work with to make a Zoom call and screen share, which could be incompatible with Google Meets and screen sharing. Indeed, that dynamic will force centralisation on a specific set of libraries just like X used to with drivers - for no particular reason other than they didn't feel like scoping out the original specification a little more practically. If all the Wayland compositors are going to be expected to use the same library, they may as well have included it as an appendix back in '08 and saved all the mucking around in the mean time.
This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.
Earlier quoted context omitted.
No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns. And because screenshots are a privileged…
That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice. There is a small risk that we end up with competing, mutua…
It depends on the app. Chances are older apps needs to be updated to use the portal.
>There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop.
No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements.
>for no particular reason other than they didn't feel like scoping out the original specification a little more practically
There was a reason. They didn't scope it out because they couldn't. Privileged operations need to be implemented using OS-specific security facilities. There's no way to make this work correctly just with Wayland. On Linux it needs a sandbox, and those are very different in scope and design from a window system.
>But hindsight is 20/20 and the wart is now quite obvious.
No, there's no wart. Or rather, if there is a wart, it's on the OS itself and how it does security. Linux didn't have a way to do this kind of sandboxing before, so someone had to invent that too. Efforts to hack sandboxing into X11 (see Qubes OS) have run into these same problems.
I'd love to take advantage of this incredible tool in MacOS. Managing windows on MacOS is quite a challenge.
I sorely miss tiling WMs when I use MacOS; Amethyst and yabai just seem to big out all the time, lose track of windows, get confused by native tabs, and deal poorly with windows that force maximum/minimum sizes. I've concluded that MacOS's window model just really doesn't mesh with tiling. My current solution, after much experimentation with tools like Rectangle, Hookshot, and Spectacle, is to use Swish[1]. It feels…
Have you ever heard of Phoenix? https://github.com/kasper/phoenix/. Despite googling around for this exact topic, with 3.8k stars I had never heard of it. Apparently someone has created slim, JS scriptable interface that is basically tailor made toward creating your own tiling WM. I just installed it and loaded one of the examples: https://github.com/nik3daz/spin2win. And what it does is basically ignores the built-in spaces and creates truly virtual desktops by just hiding and resizing windows. And it works pretty well. The response time between switching "desktops" is basically instant.