I've become a really big fan of this model of window management after using Karousel on KDE for the last 3 months. This is especially useful if you're using a widescreen monitor.
I never understood the appeal of tiling as 99% of the time I am focused on a single window at a time and I want it to take the full height of my display, so scrolling with the focused window centered is my ideal workflow.
I only wish I had the ability to quickly toggle the side-by-side mode that is default with these for the occasional time I need to have a code editor next to my browser.
If anyone knows if any of these supports that toggle, while also supporting the other key features I use in karousel (being able to shrink/expand the focused window with a hotkey), then I'd be willing to leave KDE to get that perfect workflow.
Do you not often quickly look between files? If so, odds are you're using tiles within tmux, vim, emacs, vscode, or something.
I use kakoune, which has a client/server architecture. Each kak instance I open within a project connects to the same server, so it is natural for me to use my WM (niri) to tile my terminals, instead of having something like tmux or the editor do the tiling for me.
I don't want to bother with more than one layer of WM, where separate layers don't mix.
I like physical positional cues, and being able to just flick my eyes over to other things to check status rather than having to scroll through hidden context. I have a terrible habit of losing my train of thought if I check on something that's hidden, and thereby hide my current work. So just being able to glance and then glance back is a huge plus.
I also have an insane amount of screen real estate on my work machine (2x 4K 30" displays, 1x 2K 15"), so I can have everything on screen at once. I mostly use terminals, a couple browsers, and slack, so YMMV if you are using a bunch of IDE-like windows or the like.
> I never understood the appeal of tiling as 99% of the time I am focused on a single window at a time and I want it to take the full height of my display
Even if everything is full screen, it enforces that I don't have something else hidden behind, gives me the ability to snap immediately between them (programs/workspaces) with a keyboard shortcut.
I mostly only have 1 full screen program per workspace (sway on Linux, yabai on macOS) but find that invaluable, really struggle to use say my wife's laptop with an overlapping mess of windows, where the best I can is tab between them. The main exception, where I do have them actually tile, is terminals - I don't need the full width anyway, so my workspace 1 is always 2-3 alacritty instances. Everything else that's always open is full screen in its own workspace.
Window management has been stagnant so long. I have mixed feelings about the Paper paradigm, but it's heartening to see some work in the space experimenting with the bedrock UX for operating systems, and hope we can eventually move past the floating windows approach on desktop and clumsy swipe-between-apps approach on mobile.
Agreed. All I want is to manage OS windows the same way I manage Vim windows where the content and the container are decoupled. Surprised nobody has made this yet.
Not that you likely want to hear this as a Vim user, but I believe this is how EXWM works. Windows are displayed inside Emacs buffers, which are pretty decoupled from the windows they happen to be in.
(But heck, with evil-mode maybe it'd feel pretty familiar?)
I tried exwm a couple times and the thing that got me everytime was that it was... ok... as a window manager... but actually made working with emacs as a text editor really uncomfortable. I'm talking keybindings overlap (or not), and buffer management generally. It got really confusing. (That and the single-threaded behaviour of emacs generally, freezing up etc)
No worries - I drove Doom for ~6 months and got fed up with the lag, and with Lisp. I have a wrapper for Yabai that places new windows into a predetermined number of containers and allows me to move them quickly. It works ok.
I think Hyperland or i3/Sway could also be scripted to behave this way.
I think Emacs works the same with frame/buffers. What I really like in Emacs is not having "tabs" or anything like that. I can always open any file on the filesystem, why do I care what it is open currently? Only at the moment I want to switch do I want to see a list, but I don't want to select it like some neanderthal, I want to narrow it down by typing.
I wonder how well this would work for a WM, though. Processes are a lot heavier than buffers so it kind of does matter how many are running. Unless it's a system like Android where any app expects to be oom killed at any time.
One thing I do want to mention as a vim limitation, even with neovim & it's headless+client modes, there is still only a single screen. I'd love a neovim where I can have multiple separate clients connected to the same session, but each as a separate viewpoint (but shared list of buffers, shared registers, shared so much).
Doesnt seem super applicable to window managers at the moment, but there being a singular screen does seem like a severe UI limitation.
Feedback: I highly suggest a project rename to something that does not have "sway" in the name. Reading the source it seems like it actully has no dependency, API compatibility, or direct interaction with either Sway, i3, or PaperWM?
Sway and i3 just happen to be the most well-known tiling WMs of the hour. There are a bunch of other tiling WM which seem like they will work just fine with Papersway. The docs make it seem like it should only be expected to work with Sway and i3. The possibility is high that most users will not look beyond the "NAME" section before bouncing if they are not already using either of those two and also already familiar with PaperWM.
Less urgently in the docs, it would be nice to be able to get an rough idea about what the project does and the "pitch" without having the reader research PaperWM first.
Why define it strictly in terms of other projects? Why not be usable with other tiling WMs?
my $wm_ipc_socket = $have_sway ? $ENV{SWAYSOCK} : $ENV{I3SOCK};
my $wmipc = AnyEvent::I3->new($wm_ipc_socket);
$wmipc->connect->recv or die "couldn't connect to WM IPC socket";
(One of the reasons I moved from ratpoison to i3 in the first place was that i3 has this kind of interface, though usually I use i3-msg and jq directly. I'd be curious if there are others like it...)
> This is an implementation of PaperWM-like scrollable window management for Sway/i3wm. If you like Sway/i3wm’s commitments to stability, avoiding scope creep etc. but dislike the window management model, papersway might be of interest.
https://www.youtube.com/watch?v=QifpqSiNSKA is the author showing it off (since the visual aspect is kind of the whole point.) (The little window-layout section of the status bar is neat, but I get the "monocle" version of this with stock i3 with a lot less effort - `workspace_layout tabbed` and some key bindings :-)
I'm curious how you switch between workspaces. Do you give them names? I currently keep a mental list of what each workspace is for, but I still use the standard numbers 0-9.
Sway uses workspaces as virtual desktops. Every workspace is assigned to exactly one physical display at a time. Papersway, from what I’ve read on the linked website, lives in a workspace.
PaperWM (Gnome) https://github.com/paperwm/PaperWM
karousel (KDE) https://github.com/peterfajdiga/karousel
niri (wayland) https://github.com/YaLTeR/niri
hyprscroller (hyprland plugin) https://github.com/dawsers/hyprscroller
hyprslidr (hyprland plugin) https://gitlab.com/magus/hyprslidr
PaperWM.spoon (MacOS) https://github.com/mogenson/PaperWM.spoon