This document is both the design documentation and user's manual for larswm, which is a hacked version of 9wm that adds a status bar, virtual desktops, keyboard shortcuts and most importantly, automatic window tiling. Please see Appendix F for licensing information and acknowledgements.

When I started working on larswm I had a few ideas that I think are important in a window manager. They are as follows:

  1. The user should not have to spend alot of time arranging windows on the screen, leaving more time for the actual work that he or she is trying to accomplish.

  2. Direct manipulation. Instead of accessing windows and desktops through representations of these, access them directly. That means: No icons when a window is iconified. No graphical map of the virtual desktops, larswm is fast enough that it is easier to browse the actual desktops instead, something that is very quick and easy to do, escpecially if you have a wheel mouse, and since the windows are tiled, you usually don't need much time looking at a desktop to know what's on it. And within one desktop, tiling is a good example of direct manipulation, a common way to deal with multiple windows on the screen is to overlap them and select which one you want my clicking on a representation in the form of a button on a task bar, however, larswm does not need that because the actual window, with enough content visible to know which one it is, is always visible.

  3. It must be predictable. If the user ever wonders how focus ended up on a window that he or she did not click on, something is wrong. larswm has alot of code that deals with figuring out where focus should go when different events occur.

  4. It must have a "solid" feel to it. Part of this is speed, when you switch desktops or windows are moved around as the result of being tiled it must go quick, and part of it is predictability.

  5. The window manager should not use more system resources (CPU time, virtual memory) than is absolutely necessary for performing the task of managing windows. The GUI is minimal, providing borders around the windows, and a status bar at the bottom of the screen. It provides all the feedback using plain text on the status bar.

  6. Quality control. Nowadays I test every release with Electric Fence to catch memory access errors. I also check it with gprof, to make sure no inefficient code has snuck in. So far I have been able to fix everything that I found with these tools, but I am no CS major and I am sure some things could be done better. Nevertheless, it works, and during normal circumstances it works using minimal system resources.