Skip to main content

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.

I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).

GridSelect is my answer to that. It brings up a 2D grid of windows in the center of the screen, and I can select a window with cursors keys. The window is delivered back to the caller of GridSelect, and for the moment the most useful thing it does for me is to raise and focus the selected window. The advantage over the presentation of Tabbed is that there is much more space for window titles, that are now not forced into a single row at the top of the screen, but can occupy multiple rows. Also navigating a 2D grid is also much faster than navigating a linear 1D structure.

GridSelect colorizes the cells according to the window class of displayed window. So, all windows with the same class get the same color, and after a while I start to remember which window class has which color. E.g., when I want my xchat window, I just have to search for light green, or if I want an emacs windows, I have to focus on dark violet.

Although GridSelect wasn't meant for inclusion into xmonad-contrib, dons was quick to merge it into the darcs repo. ATM I'm using the following key binding fragment:

((modMask, xK_f     ), (gridselect defaultGSConfig) >>= (\w -> case w of
Just w -> windows (bringWindow w) >> focus w >> windows W.shiftMaster
Nothing -> return ())


There are a few ideas that I haven't found time to toy with. First I like the window arrangement to be more static. At the moment, the windows are sorted (by XMonad) according to its last use and GridSelect arranges them spiraling outwards in a diamond like pattern. Mentally, I can only keep track of the last two to three windows, so that I can blindly select them. For everything else, I have to read titles. It would be more helpful to give fixed spots to windows. Of course, windows get deleted and new windows pop up all the time, so probably it would be good to defragment and resort according to display time with a special key.

Substring search on window titles is another idea. As GridSelect uses cursors keys for the moment, the rest of the keyboard could be used to enter the string used in searching. GridSelect should then gray out the windows that do not contain the search term.

I guess I won't hack on these ideas immediately as GridSelect ATM does what it should do, namely lower the time that I spend searching for windows significantly.


Anonymous said…
Thanks for creating GridSelect, CFruhwirth. It's super useful in so many ways.

Wanted to post a quick comment that a few things have changed since the first early version of GS went to the xmonad mailing list. So people will find they need to alter the example a bit for it work.

For help using GridSelect (which btw can be used for just about anything you can do with xmonad now, not just focus windows....) please see the documentation on

or stop by IRC at #xmonad on freenode irc channel.
Myke said…
Excellent viewpoint to window managing. I am myself an expander and have little use for GridSelect as is (although I could use a GS customized to select workspaces:) but it is so nice to see how versatile this little WM is.

Popular posts from this blog

Liskell standalone

Some time has passed since I last blogged about Liskell. It is not dead nor have I changed my mind that Haskell needs a proper meta-programming facility not to mention a better syntax.Liskell was a branch of GHC once. Now it sits on top of the GHC API, or I should rather say sneaks behind its back as it creates its own API as the original one is not suitable for the stunts I'm interested in. If Liskell sticks with GHC as its soil, I will definitely send patches upstream to refine the GHC API in the areas where it needs more flexibility for Liskell. However for the moment, my main target was to get something out that compiles with a stable version of GHC.You can grab it with the usual: darcs get This version has been tested with ghc 6.10.1 and should install like: ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install cd LskPrelude make install-inplace Optionally you can run make tests in the testsuite subdirectory. Thanks to community.haskell…

Removing CHS based access from windows boot loaders

Recently, I had troubles to migrate my Windows installation from VMWare to VirtualBox. When booting the vmware created partition in virtualbox, I got "NTLDR not found". So I sharpened the knives and got down to business with vmware's gdb interface and virtualbox's internal debugger. Tracing the execution showed that the BIOSes of the two products reported different geometries on the INT 13h interface. The generic method contained in the boot loader to read a sector from disk is "clever" as it checks whether the sector is below the maximum sector index that is reachable with the CHS geometry reported by the BIOS. If not, it uses the LBA interface of the BIOS. If yes, the cleverness of the boot loader suddenly vanishes. Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block. That's a section of the first sector embedded into the boo…