The Window Manager I Want
Since I first discovered ratpoison in 2005 or so, I’ve basically exclusively used tiling window managers, going through, over the years, StumpWM, Ion 3, and finally XMonad. They’ve all had various strengths and weaknesses, but I’ve never been totally happy with any of them. This blog entry is a writeup of what I want to see as a window manager. It’s possible that some day I’ll get annoyed enough to write it, but maybe this post will inspire someone else to (Not likely, but I can hope).
Layout
At any given moment, the screen1 is divided into one or more panes. These panes always tile the screen. Each pane may or may not currently be displaying a window. If it is not, then the desktop will be displayed in that pane.
The primitive operations you can perform on the pane include, but are not necessarily limited to:
- Split
- Splits the focused pane into two equally-sized panes, either horizontally or vertically. One of the child panes will display whichever window the previous pane displayed, the other is empty.
- Resize
- Change the relative size of two child windows that were split from the same parent.
- Kill Pane
- Destroy the current pane. If it is displaying a window, that window is not sent a close message. The pane’s sibling window expands to consume its space.
- Next/Previous pane
- Focus the next or previous pane. Panes are ordered based on position on the screen, regardless of how they were split to arrive at the current layout.
- Goto Pane
-
Panes are numbered, based on their location on
screen.
Mod-Nfocuses the Nth pane.
Selecting windows
There is a global list of all windows. Windows are ordered arbitrarily
in this list (maybe based on the order they were opened?). Every
window has a name, which is initially set to the WM_NAME property
set by the window’s client.
The following operations are available to manipulate windows:
- Next/Previous Window
- Replace the window in the current panel with the next or previous window in the list.
- Rename
-
Prompts for a new name for the current window. If the user
enters an empty string, the window reverts to the default
behavior of using the
WM_NAME. - Goto Window
- Prompts for the name of a window to switch to. This prompt matches on substrings or even sub-sequences of the window name, displaying the result of the selection as you type. After typing some characters, you can scroll through the list to select an entry, instead of completing typing.
- Kill
- Sends a close message to the window in the focused panel.
Desktops
It seems likely I will want multiple desktops. Each desktop will have
its own pane layout. However, the window list is still global, not
per-desktop. Goto Window will always operate on the global window
list. Selecting a window that is visible through a pane somewhere else
causes that pane to become empty.
Alternately, there is no concept of multiple desktops. However, there is the ability to save and restore layouts, meaning both the layout of the panels on the screen, and the list of which window is in each pane. The primary difference here is that a window can be associated with multiple panes in different saved layouts, and gets resized/moved as necessary as you switch panes. I suspect I like this model better.
Postscript
If this sounds familiar to you, it probably should. What I’ve described is essentially identical to how emacs manages buffers and windows (analogous to X windows and panes in the above, respectively), with window-number.el and either iswitchb or ido. I manage hundreds of buffers in emacs this way, and complicated screen layouts, whenever I’m doing any hacking, and I love it.
I would in fact be tempted to write my window manager into emacs itself, except for the annoying fact that emacs is very much single-threaded. It’s already annoying enough when network drops and a hung network filesystem takes down my emacs waiting for a timeout; It would be utterly unacceptable if that took down my entire window manager, too.
I’d alternately be tempted to try to make this an XMonad plugin, but I think that it’s sufficiently different from XMonad’s data model that the impedance mismatch would suck.
Footnotes:
1 I’m only going to consider the single-monitor case for now, but the generalization should be easy.
I’ve found that one wants reasonably integrated and functional floating window support (XMonad’s emphatically doesn’t count) for otherwise-functional applications with broken UIs.
(Also, I kind of like the stack-of-windows-in-a-pane implied by ion3, too bad about the rest of it…)
Yeah, I didn’t mention it, but I do also want a floating layer that works. And I agree that XMonad’s doesn’t count.
Hrm. I wonder how hard it would be be to proxy between X and another window manager, and let it manage /some/ of your windows. It might be fun for your floating layer to just be an instance of metacity that only gets to touch the windows you tell it to…
FWIW, the floating layer is entirely integrated into xmonad’s core structure — perhaps too well integrated. alt-drag to float, mod-t to tile. What “doesn’t count” about the xmonad integration?
The conceptual splitting of panes and client windows is certainly possible — reminds me of ion3.
The main things that I find lacking about XMonad’s floating layer are:
XMonad.Layout.Tabbedlayout, so this bites me frequently.These issues come up pretty often in the ways I want to use the floating layer, and so they make it fairly frustrating for me to use.
Hey Nelson,
I, like you, have never been completely and totally satisfied by a tiling window manager. I currently use XMonad, and have always wished I could use it more like emacs.
Have you tried StumpWM? It’s an emacs-inspired wm with full support for screens (desktops) and emacs-style frames. I tried it long ago but wasn’t willing to invest the time to get it 100% how I like it at the time. Maybe I’ll give it another go.
Also, have you tried implementing frames in XMonad? Like Don says, it feels possible with a custom layout manager, a few keybindings, and some dzen popups for typing / auto-completing which window to swap into the frame when switching buffers/windows. I’ve wanted to give this a try for a while now.
I have to agree — XMonad’s floating layer often angers me, but when it comes to programmable WMs, just as with programmable text editors, you only have yourself to blame :P.
RJ
I don’t understand. Do you mean “raise” as in promote to the top of the stack? If so, bind say, alt-shift-leftclick to “master”. If you mean “float” (for “raise”), alt-leftclick does this already.
Is an artifact of using the full layout with floating. The floating layer is integrated into the stackset. Sadly, the code is significantly more complex to manage the float layer as an entirely separate stack.
Have you looked at awesomewm recently? It’s pretty close to what you’ve described and is modular/extensible enough that an ido-like window/layout switching scheme shouldn’t be difficult to implement.
Wow you just described my ideal window manager! I’m using awesomewm right now, but there is a few things that bug me still.
Uh, how well have you tested ion3? It shouldn’t be that hard to change the small differences from the standard config to to exactly what you want.
(ion is a bit dead at the moment, but it is also very complete)
You should try out Musca. Uses manual tiling, does more or less everything you mentioned, with the exceptions of manual window naming and its window list being per-desktop, but neither of those would be terribly difficult to change, if it’s that much of a problem (after all, you could largely just copy the existing group/desktop name handling, and combine the per-desktop window lists). Also lets you do neat stuff like load/dump group layouts from/to file, on the fly.
Nobody mentioned ratpoison?