I actually wound up switching off i3 (well, sway, but they’re basically the same) because I kept getting things into weird situations where I didn’t understand how the tiling works. Containers with only one child, that sort of thing.
river, my current wm, has an interesting model: the layout management is done in an entirely separate process that communicates over an IPC mechanism. river sends it a list of windows, and the layout daemon responds with where to put them.
Also, since you brought it up: sway is almost entirely compatible with i3. The biggest missing feature is layout save/restore. But it can do one thing i3 can’t do, and that’s rearranging windows by dragging them.
That’s pretty much why I wrote river. I was using sway beforehand as well but grew increasingly frustrated with how much implicit state i3-style window management required me to keep in my head and how unpredictable that state makes managing windows if your mental model/memory of the tree isn’t accurate.
I’m in the same boat (pre-switch). I use sway but, after many years, still don’t really understand how I sometimes end up with single child (sometimes multi generational) containers.
My personal ideal was spectrwm, which simply had a single primary window and then, to the right, an infinitely subdividing tower of smaller windows which could be swapped in. I briefly toyed with the idea of writing a wayland spectrwm clone.
That sounds exactly like the default layout of dwm, awesomewm, xmonad, and river. If you’re looking for that kind of dynamic tiling on wayland feel free to give river a try!
Your reasons for spectrwm (and xmonad’s, etc. model) is exactly the reason I use tiling window managers like i3, exwm and StumpWM: I don’t like that dynamic at all ;-)
No accounting for different tastes.
Is there a name for those two different tiling models?
I was also quite lost with the way tiling works at the beginning. There is not much resource around this subject. It seems people just get used to it and avoid creating these useless containers. I am lucky, it was my case.
I rarely use the advanced features of i3 and always keep it at relatively simple layouts. The trick, for me, that puts it miles above the rest when coding is to use an editor that works with it rather than against it. Then life becomes awesome and you really can say “Unix is my IDE”.
Every advanced editor I know, including Vim, insists on doing its own version of window management inside the window that it runs in. This is incredibly backwards. That means that you have shortcuts for moving between windows/tabs that contain programs and a different set of shortcuts for moving between files you have open. This introduces a lot of extra work for no gain at all if you want to primarily use the keyboard for navigating. (Which most of the people that use i3 or Sway want, I’d think.)
Eventually, my default layout for Neovim consisted of three columns. The first two showed the files I was editing (say, the code and the test for the code) and the third would be Neovim’s terminal emulator in which I would run the tests, so I could cycle quickly through them. So I had a terminal emulator inside a window in an editor that ran in a terminal emulator in a window just to have some convenient ergonomics. This is madness, I realized.
And then I discovered Kakoune. It respects the WM you put it in (tmux is also fine) and now I can just mix and match files and shells however I please. And that is just the first of a few good ideas it implements. If you use a tiling window manager, you really must try it.
Every advanced editor I know, including Vim, insists on doing its own version of window management inside the window that it runs in. This is incredibly backwards. That means that you have shortcuts for moving between windows/tabs that contain programs and a different set of shortcuts for moving between files you have open.
I had the same complaint but ended up with the opposite conclusion: run all your X windows inside your editor and then it’ll be beautifully consistent: https://github.com/ch11ng/exwm Only one set of key bindings for everything!
Every advanced editor I know, including Vim, insists on doing its own version of window management inside the window that it runs in. This is incredibly backwards.
Totally agree, as an emacs user new “windows” being spawned is always annoying. There are whole plugins to combat this like frames-only-mode: https://github.com/davidshepherd7/frames-only-mode , which forces emacs to spawn an actual new “WM window” (frame in Emacs lingo).
But I use Emacs -nw in the terminal and it all becomes a mess quickly. I kinda just live with it the way it is.
This is such a great writeup Vincent, especially the tree visualisation of how the tiles work. I went down the Xmonad -> dwm path, but this has given me enough motiviation to finally try.
(The guide is also worth checking out for the guide to polybar).
If you’re setting up i3, scratchpads will be a life-changer. Alt+c to show/hide calendar, Alt+f to show/hide file manager, Alt+` to show/hide temporary console, etc. Also, look into file-manager driven workspaces -vs- console driven workspaces.
I don’t know if there are any posts about it. Basic idea is Alt+enter brings up ranger rather than console and you quickly traverse (via t, f, or g commands) where you need, then open the file you want to edit, the file manager closes, and file opens. So you don’t do any cd, or ls but interact with everything via a file manager. If you need a shell, you press s. Second approach is you Alt+enter to open a console, then use cd, ls, z or asdf to navigate where you need, then vim file and work this way. This is the default console driven approach. And third way is actually vim driven workspaces. When you do everything via vim. Alt+enter opens vim and not shell. If you need shell, you :sh or :terminal. In the first case file manager is the first class object, in the second case it’s shell/bash, and in third it’s vim. My personal approach is file manager driven workspaces.
I’m using a similar setup (i3-gaps + polybar). Some notes:
picom (and any other compositors) takes its toll on your GPU and battery and noticeably increases input latency. I found it not worth the performance hit.
I use xcompmgr (picom’s grandparent iirc) but with nothing done besides the compositing: no alpha nor anything. It doesn’t use more power and it actually helps on a variety of hardware+software nowadays. It might add one frame of latency but considering the typical latency of editors themselves, it’s not the usual issue.
I appreciate that people love i3, but I don’t like the tiling behaviour, so I still with (not)ion[1] when I’m running X. It has a lot of the same qualities (small, tiling, keyboard-driven) but the placement and organization of the tabs is manual, as opposed to automatic.
I have to use mac for work, and I use both mac and linux at home.
I like i3 a lot. But, I found a good enough substitute with KDE and https://github.com/kwin-scripts/kwin-tiling, and it gets me close to cross platform (or at least cross windowing) behavior compatibility on mac and linux…
On the mac I use yabai/skhd (https://github.com/koekeishiya/yabai and https://github.com/koekeishiya/skhd). I have key bindings set up to be close enough to the same with yabai and kwin-tiling, with close enough behavior, so that most of my tiling and resizing windowing behavior is the same on mac and linux.
I made a similar switch a while ago, awesome to sway, because one game (Cyberpunk 2077 with wine) was crashing my whole computer randomly under awesome.
I managed to make a usable configuration but I still miss awesome a lot because of:
the lack of workspace aware alt-tab: this is the most frustrating thing, I just can’t understand how it is considered acceptable to rotate through all windows regardless of workspace, I never want that;
my feeling that my configuration is made of a dozen loosely coupled pieces.
An alternative could be Qtile. I have never tried it myself, but it looks like Awesome with Python and it works on both X11 and Wayland. I didn’t know about it before starting on i3, but I think I would have given a try.
Very interesting indeed, Qtile has a strong feeling of awesome-but-with-python. Sadly the lack of systray when in wayland and more importantly of XWayland support make it a non-starter for me. I’ll keep it on my radar nonetheless.
I actually wound up switching off i3 (well, sway, but they’re basically the same) because I kept getting things into weird situations where I didn’t understand how the tiling works. Containers with only one child, that sort of thing.
river, my current wm, has an interesting model: the layout management is done in an entirely separate process that communicates over an IPC mechanism. river sends it a list of windows, and the layout daemon responds with where to put them.
Also, since you brought it up: sway is almost entirely compatible with i3. The biggest missing feature is layout save/restore. But it can do one thing i3 can’t do, and that’s rearranging windows by dragging them.
That’s pretty much why I wrote river. I was using sway beforehand as well but grew increasingly frustrated with how much implicit state i3-style window management required me to keep in my head and how unpredictable that state makes managing windows if your mental model/memory of the tree isn’t accurate.
link to the project: https://github.com/ifreund/river
Looks interesting!
I’m in the same boat (pre-switch). I use sway but, after many years, still don’t really understand how I sometimes end up with single child (sometimes multi generational) containers.
My personal ideal was spectrwm, which simply had a single primary window and then, to the right, an infinitely subdividing tower of smaller windows which could be swapped in. I briefly toyed with the idea of writing a wayland spectrwm clone.
That sounds exactly like the default layout of dwm, awesomewm, xmonad, and river. If you’re looking for that kind of dynamic tiling on wayland feel free to give river a try!
I will! I had some trouble compiling it last time I tried. But I will return to it.
Feel free to stop by #river on irc.libera.chat if you run into issues compiling again!
Your reasons for spectrwm (and xmonad’s, etc. model) is exactly the reason I use tiling window managers like i3, exwm and StumpWM: I don’t like that dynamic at all ;-)
No accounting for different tastes.
Is there a name for those two different tiling models?
automatic vs manual?
I’ve seen the terms static (for when the containers have to be created by the user) vs dynamic used.
ArchLinux seems to call them dynamic vs manual. See the management style column https://wiki.archlinux.org/title/Comparison_of_tiling_window_managers
I was also quite lost with the way tiling works at the beginning. There is not much resource around this subject. It seems people just get used to it and avoid creating these useless containers. I am lucky, it was my case.
I rarely use the advanced features of i3 and always keep it at relatively simple layouts. The trick, for me, that puts it miles above the rest when coding is to use an editor that works with it rather than against it. Then life becomes awesome and you really can say “Unix is my IDE”.
Every advanced editor I know, including Vim, insists on doing its own version of window management inside the window that it runs in. This is incredibly backwards. That means that you have shortcuts for moving between windows/tabs that contain programs and a different set of shortcuts for moving between files you have open. This introduces a lot of extra work for no gain at all if you want to primarily use the keyboard for navigating. (Which most of the people that use i3 or Sway want, I’d think.)
Eventually, my default layout for Neovim consisted of three columns. The first two showed the files I was editing (say, the code and the test for the code) and the third would be Neovim’s terminal emulator in which I would run the tests, so I could cycle quickly through them. So I had a terminal emulator inside a window in an editor that ran in a terminal emulator in a window just to have some convenient ergonomics. This is madness, I realized.
And then I discovered Kakoune. It respects the WM you put it in (tmux is also fine) and now I can just mix and match files and shells however I please. And that is just the first of a few good ideas it implements. If you use a tiling window manager, you really must try it.
I had the same complaint but ended up with the opposite conclusion: run all your X windows inside your editor and then it’ll be beautifully consistent: https://github.com/ch11ng/exwm Only one set of key bindings for everything!
Totally agree, as an emacs user new “windows” being spawned is always annoying. There are whole plugins to combat this like frames-only-mode: https://github.com/davidshepherd7/frames-only-mode , which forces emacs to spawn an actual new “WM window” (frame in Emacs lingo). But I use Emacs -nw in the terminal and it all becomes a mess quickly. I kinda just live with it the way it is.
My path was:
I am thankful to i3 for being a gateway drug.
This is such a great writeup Vincent, especially the tree visualisation of how the tiles work. I went down the Xmonad -> dwm path, but this has given me enough motiviation to finally try.
(The guide is also worth checking out for the guide to polybar).
If you’re setting up i3, scratchpads will be a life-changer. Alt+c to show/hide calendar, Alt+f to show/hide file manager, Alt+` to show/hide temporary console, etc. Also, look into file-manager driven workspaces -vs- console driven workspaces.
Unable to find any links by quickly searching for file-manager driven workspaces/console driven workspaces - could you point me to something?
I don’t know if there are any posts about it. Basic idea is Alt+enter brings up ranger rather than console and you quickly traverse (via t, f, or g commands) where you need, then open the file you want to edit, the file manager closes, and file opens. So you don’t do any
cd, orlsbut interact with everything via a file manager. If you need a shell, you presss. Second approach is you Alt+enter to open a console, then usecd,ls,zorasdfto navigate where you need, thenvim fileand work this way. This is the default console driven approach. And third way is actually vim driven workspaces. When you do everything via vim. Alt+enter opens vim and not shell. If you need shell, you:shor:terminal. In the first case file manager is the first class object, in the second case it’s shell/bash, and in third it’s vim. My personal approach is file manager driven workspaces.That is an interesting way to think about it - will give it a shot - thanks!
I’m using a similar setup (i3-gaps + polybar). Some notes:
I use xcompmgr (picom’s grandparent iirc) but with nothing done besides the compositing: no alpha nor anything. It doesn’t use more power and it actually helps on a variety of hardware+software nowadays. It might add one frame of latency but considering the typical latency of editors themselves, it’s not the usual issue.
I appreciate that people love i3, but I don’t like the tiling behaviour, so I still with (not)ion[1] when I’m running X. It has a lot of the same qualities (small, tiling, keyboard-driven) but the placement and organization of the tabs is manual, as opposed to automatic.
[1] https://notionwm.net/
Nice write-up! I run a much more vanilla i3 setup but learnt a few things - I’m definitely going to check out autorandr at the very least.
I hardly ever use the more advanced tiling features of i3 (or sway these days actually, but anyway). I use it mostly for two reasons:
These two points make the UX of this setup several times better than any other I know of.
I have to use mac for work, and I use both mac and linux at home.
I like i3 a lot. But, I found a good enough substitute with KDE and https://github.com/kwin-scripts/kwin-tiling, and it gets me close to cross platform (or at least cross windowing) behavior compatibility on mac and linux…
On the mac I use yabai/skhd (https://github.com/koekeishiya/yabai and https://github.com/koekeishiya/skhd). I have key bindings set up to be close enough to the same with yabai and kwin-tiling, with close enough behavior, so that most of my tiling and resizing windowing behavior is the same on mac and linux.
It’s not perfect but it’s pretty good.
I made a similar switch a while ago, awesome to sway, because one game (Cyberpunk 2077 with wine) was crashing my whole computer randomly under awesome.
I managed to make a usable configuration but I still miss awesome a lot because of:
I really just want awesome-on-wayland.
An alternative could be Qtile. I have never tried it myself, but it looks like Awesome with Python and it works on both X11 and Wayland. I didn’t know about it before starting on i3, but I think I would have given a try.
Interesting, I’ll take a look. That’d be the occasion to learn Python.
Very interesting indeed, Qtile has a strong feeling of awesome-but-with-python. Sadly the lack of systray when in wayland and more importantly of XWayland support make it a non-starter for me. I’ll keep it on my radar nonetheless.
Sometimes it’s worthwhile to run a dedicated xserver for a game only.