Great project but I truly believe that these single screen window managers are going to be a thing of the past if Scrollable WMs manage to find some more marketting. Niri[1] and PaperWM[2] for example, these Scrolling WMs provide a way to tile your apps in a way that feels natural. It's like having multiple monitors without having multiple monitors. When I first used PaperWM on Gnome, I just couldn't think of a reaso…
Oh wow. After bouncing off tiling wms for years, I just enabled PaperWM on PopOS and immediately love it. I kind of want this everywhere - phone, Mac, etc.
Great project but I truly believe that these single screen window managers are going to be a thing of the past if Scrollable WMs manage to find some more marketting. Niri[1] and PaperWM[2] for example, these Scrolling WMs provide a way to tile your apps in a way that feels natural. It's like having multiple monitors without having multiple monitors. When I first used PaperWM on Gnome, I just couldn't think of a reaso…
It's a personal preference thing. I've never liked tiling WMs. I have no use for tiny little stacked terminals / windows. But, I know folks who will never do anything other than a tiling WM. (I'm writing this from Niri, by the way. It is excellent.)
Tiling WM for me is the ability to use every app full-screened, with any key combination for accessing it. It’s so great on a laptop that I’m — a macOS user for over a decade — unwilling to use anything but a tiling WM on my laptop ever again. It’s a perfect WM for me already, in every single way. An actual tiling thing, when you open multiple windows on one screen, is something that I never use. Or maybe just once in a blue moon.
You can implement hot corners on Wayland using layer-shell and creating a 1px transparent surface on each monitor corner.
Can you? I grant that you can probably trigger like that, but does Wayland have a generic way to move+resize windows?
> does Wayland have a generic way to move+resize windows?
I'm not entirely sure what you mean here or how it is related to hot corners.
The compositor itself can move windows anywhere (it is in full control). A client moving the windows of other clients is not permitted, although compositor-specific interfaces exist for this. There's no standard here because a stacking compositor implements completely different semantics from a tiling compositor. I'm sure that protocol extensions will come up for niche use cases over time.