Guest post by Calm window manager (mainly known for its shorthand name cwm) is a member of a once-powerful and now-declining family of minimalist X11 window managers. It is relatively unknown outside the OpenBSD community, but it deserves more notice.
Background
The development of cwm was started back in 2004, when Marius Aamodt Eriksen released a rewrite of evilwm, needed to support several new features that were difficult to implement in evilwm’s code base. After year of development the original author lost interest and stopped updating cwm.
The project was reborn in April 2007, when it was imported into OpenBSD’s base. A bunch of new features were added within a couple of months and cwm replaced wm2 as OpenBSD’s minimalist window manager in November 2007 with the release of OpenBSD 4.2.
Mouse-less window management
The main goal of every minimalist window manager is to get out of the user’s way. Cwm is pretty good in doing so – it allows the user to manage windows with keyboard shortcuts so that one doesn’t actually need to touch the mouse.
Everything can be done from the keyboard: resizing, moving, hiding, raising or lowering windows, etc. Cwm has different shortcuts for resizing and moving windows by 1px and by 10px, and a shortcut to resize a window to full screen. Naturally, the default shortcuts are vi-like.
Furthermore, cwm can be configured to move the mouse cursor, so that one could use the computer without any pointing device.
Searching the lists
Using cwm mainly involves searching. Launching applications, switching windows, connecting to other hosts using SSH – everything can be done by searching the relevant list.
The main principle is the same for all these actions: cwm shows a list of relevant content (executables in $PATH, ./.known_hosts file entries, windows names) and removes the entries that doesn’t match the user’s input.
Window groups
There is no virtual desktop concept in cwm. Instead it supports window groups, which can be used to emulate virtual desktops in a similar manner as they are in most dynamic window managers.
Each window can be assigned to any number of groups. The groups themselves can be manipulated the same way as windows – they can be hidden, lowered and raised with shortcuts.
In order to make groups behave as virtual desktop the user can enable the sticky mode, so that all new windows would be assigned to the default group.
Configuration
Several aspects of cwm may be configured by editing ~/.cwmrc. The user may add, modify or remove shortcuts, change colors and other aspects of window management behavior.
Arbitrary commands can be bound to key combinations. The only default binding is the invocation of xterm by pressing control, meta (left alt) and enter keys simultaneously.
Additionally, the user may configure screen border offsets, so that cwm can be used with external toolbar like dzen, xmobar, xstatbar or even as a window manager for GNOME.
The new settings can be applied to running instance of cwm without restarting the session.
Conclusion
The word calm in the cwm’s name isn’t accidental. After getting accustomed to its key bindings and some configuration you nearly forget about it. It just moves out of your way, so you really don’t find yourself distracted from your tasks.
Give it a try!
Been running cwm for over six months now! It just works!
Thanks Dmitrij for the write up, I wasn’t aware of this style of window manager.
I like these kind of articles — a nice and compact introduction to something I wasn’t familiar with.
Way too much “my GUI/OS/WM/etc is best because it glows in the dark” kind of BS in this world. It’s good to hear how others try to solve useability issues and enhance the user experience in their own productive and positive way, even if I have and probably will never personally use this specific WM. Thanks!
“The main goal of every minimalist window manager is to get out of the user’s way”
Sadly, with a keyboard interface, a window manager does exactly the opposite, by forcing the user to learn all the invocations she needs to get stuff done. It’s slower, and demands more of the user than a simple point-and-click interface. The idea of a mouse-less graphical interface is an anomaly, which doesn’t prove correct.
It may take longer to learn, but can often be much faster to use in practice. Plus, cwm gives visual feedback by narrowing your choices to those selected by your search input. So this does not equate with a return to the command line where your argument is more applicable.
You misunderstood me, I’m not referring to slowness of learning, but to slowness of usage.
First, a mouse-based interface has been proven to be faster than a keyboard-based interface. While I’m sure that constant use of a specific interface over a long time can get you to be very fast on a given application, but across the board, mouse-based interface is faster.
Second, a mouse-based interface is ubiquitous. A click on a window is the same in a window-manager, a browser, a media player etc. Keyboard-based interfaces each have their own choice of shortcuts; so you have a situation where the same action might have different shortcuts in different applications, and the same shortcuts can perform different actions in different application. It gets worse when, as mentioned before, some frequently-used shortcuts become wired to your muscle memory and you start performing them everywhere, to hilarious results.
That heavily depends on what the interface… interfaces to, what kind of program or functionality. But I’ll assume that you don’t make a generic claim here (which would obviously be nonsense), but consider the operations of a window manager, which is managing windows (and maybe applications).
The keyboard removes the requirement of nearly pixel precise movement of the mouse. For example, a common way to move a window on the screen is pressing the Alt key and clicking somewhere into the window, then dragging it. In case a window manager uses title bars or tabs to move a window, you need to place the mouse pointer into it, which requires more precision. Resizing a window by “picking” its narrow border also requires precision. Alternative? Press Alt, hold down the right mouse button anywhere inside the window and resize the window as you like.
The concept of “pointing anywhere into a window and then pressing a key for a certain action” (where “key” may refer to a key on the keyboard, or the combination of a modifier key of the keyboard and a mouse key click, e. g. Alt + right mouse button) is very comfortable, especially if you consider the enormous amount of X window managers, compared to what “Windows” can do. Foreground, background, focus (yes, independent of each other!), maximize, restore, minimize, roll up, hide, move to different virtual workspace, close, capture, window overview, send to printer… lots of things that would take more time to achieve using a mouse. Just imagine every window would require 20 buttons for just the “average” amount of functionality in the title bars, or those functions had be listed in some lengthly menue… oh, and add buttons for virtual workspace management and so on.
I may add an individual note: I like window managers that provide a good combination (!) of mouse interactions and keyboard shortcuts. Currently I’m using WindowMaker with a “programmable keyboard” (Sun USB Type 7), using the 2×5 matrix on the left for window managing functions primarily. So I’m not advocating a mouse-less interface, just as I don’t recommend a keyboard-less interface, but in my opinion and experience, the key to productivity is a good and reasonable combination of both. This combines both the power of a window manager with easily employing that power in everyday use, which traditionally benefits productivity in general.
Especially on small-sized displays, e. g. “service laptops” (often netbooks) where you have to deal with 800×600 or 1040×600 (or something in that relation), you will be happy to be able to manage your windows using the keyboard. Why? Because – 1st argument – the available pointer, typically a glide pad, is very unprecise to “pick” things like window corners or tiny buttons, and – 2nd argument – you don’t have screen real estate to waste for control elements, because the screen appears to be too small anyway. (I’m still using a 500 MHz AMD laptop with a 800×600 screen for diagnostics and setup, and it works excellently with a manually configured version of fvwm2 with good keyboard and mouse controls setup.)
As you mentioned that you’re not going to challenge the massive impact of learning, I won’t provide arguments for that; I’ll leave it to the educated reader as an exercise. 🙂
This is something I won’t argue with you. 🙂
You’re over generalizing. There are definitely cases where a mouse-based interface is dog-slow compared to keyboard interface. In fact I’d be willing to challenge you to a text editing contest where you use the GUI of your choice against my use of the Linux TUI with tools such as vim etc.
Having said that, there are many cases where users can communicate their intentions more efficiently with a GUI. It’s just far from a universal truth.
To bring it back to the topic at hand; my feeling is that the Calm window manager allows users to be very efficient, perhaps much more so than say the new Gnome WM.
Citation needed.
I have yet to find a heavy-mouse user who is faster than a heavy-keyboard user. Especially when it comes to “typical” secretary work (document creation, document formatting, file management, e-mail, website updates, accounting, etc). A steno who knows keyboard shortcuts for everything is many, many, many times more productive than one who only knows which icons to click on.
I strongly disagree. A mouse-based interface is easier to learn, but a keyboard interface to the same mouse-based interface will be faster.
For example, to save a file in a word processor:
ALT+F, A
type filename
enter
Is much easier/faster than:
mouse hand to mouse
move mouse to top-left corner of window, click on File menu
move mouse down to Save as, click
type filename
move mouse to OK
That’s a poorly thought out interface then, and not the fault of the entire category. The same can be said for mouse-based interfaces where sometime single-clicking activates an item, sometimes double-clicking activates an item, sometimes drag’n drop activates a menu, sometimes drag’n drop doesn’t, some apps have menus, some have icons, some have ribbons, etc.
And that’s different from mouse-based muscle memory? You ever watched a very proficient MS Word 2003 user switch to 2007 the first time? Or an MS Word 6 user siwtch to 95+ the first time?
Alright, first, the obligatory links:
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
http://www.asktog.com/TOI/toi22KeyboardVMouse2.html
http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html
http://www.plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index….
Second, cwm is a window manager, not a text editor, a terminal etc. While I’m sure find /foo/bar/*.c | grep baz | xargs whatever is a zillion times faster than doing that using a GUI, this isn’t what we’re discussing here (or at least isn’t what I’m discussing (; ). A window manager, by definition, manages windows, for which a mouse is, again, proven to be faster than keyboards, and more ubiquitous. You may try to exaggerate with “you have to learn to click this button for this and that button for that”, but that’s not what the interface is, what you have to learn is left-click, right-click, double click, maybe wheel-scroll, and this applies to windows, menus, tabs, inside a browser, in an editor, you name it. And while I’m also sure someone who uses Xwm (replace X with your own flavour) for 3 years can make windows dance around with his keyboards, that is an edge case, which doesn’t apply for the other 99% of cases.
Again, I’m not suggesting that you should do your coding, sysadministrating, dba-ing, or whatever in a GUI, I “live” inside screen, bash, and Emacs because these give me the superior environment for what I do. But I run all those inside Gnome-Shell because it does what I need, window management wise, and doesn’t interfere with anything else. Same reason I use Firefox rather than, dunno, lynx. Choose the right tool for the right job. You won’t code with your mouse, and you, I think, better with a mouse when you use a GUI.
Well, with any piece of software You have to learn something. With point-and-click interface You still have to learn the types of action invoked by right/left/middle click (or modifiers on Mac), menu structure, wordings and so on. It’s less visible, but still relevant. And it is plain wrong that point-and-click interfaces are easy to use. Eg., my father gets very puzzled with everything in Windows, while he was very comfortable with DOS and NC.
For me it was easier to learn Vi keys and install the software which knows that. That said, my first computer was running brand new Windows 3.1 (not 3.11), and I switched to UNIXes after a couple of years in XP.
So true, and there were even several studies on this. But this is only valid for newbie users, as the rest of us have their habits.
“The idea of a mouse-less graphical interface is an anomaly, which doesn’t prove correct”
It’s “correct” enough for me, and that’s what matters to most people. Some like keybinds and some like clicky-clicky, horses for courses.
Cwm has become my primary WM, meaning it’s the WM that’s set in my ~/.xinitrc to launch when I do a “startx”, but I tend to rely of ScrotWM more often (which I can launch from within Cwm via the “exec WindowManager” option) these days. Personally, I tend to get stuff done much faster with their keyboard driven setups, especially combined with other Vi-like programs (Vim, Uzbl, Vimperator, Tmux…etc). Only times I see myself reach for a mouse or stylus is when I’m on graphics apps like Inkscape, GIMP, BibblePro or Photoshop (Wine).
That’s funny. I think there aren’t any applications (well besides web browsers) where I enjoy shortcuts more than in these two.
I have been using i3/wmii/xmonad (and similar window managers) for a very long time. It all looks awesome when you start with, but then you launch your first applications, open an ssh connection, start tmux inside and so on and suddenly your shortcut does three actions at once. And then the problems begin. You change key bindings, but then their interfere in other situations, so you make more complicated key bindings, holding down more buttons and in the end you have real problems because of your brain has problems to keep up with all this short cuts and you somehow decouple from what your fingers do there. In the end you give up and find out that things looked faster, because you constantly hammered on the keyboard, but efficiency decreased. Then you start to learn all these nifty ideas people had for interfaces using the mouse. You regret that you didn’t learn these things earlier.
My conclusion (until now) is that you have to use the right tool for the job. For example stuff like vim are nice and alt-tab is cool, because you use both of them without interrupting your thought process, but when you switch between something like programming and chatting then the mouse seems to be the right approach. The same is true for lots of other things.
One of the best approaches so for is the way Plan 9 and a lot of its applications do it, but the “modern world” sadly doesn’t fit with this. I really would like to see something like acme in the real world. It also supports HTTP/basic WWW, but you can’t really use it for your every day stuff.
I have also been a great fan of browsers vimperator and conky for a while. Sadly they interfere with web sites that are already developed for efficient use. Oh and using them together with an “efficient” window manager is an absolute hell. Way too many key bindings with the same meaning.
Edited 2011-11-23 14:39 UTC
Being myself an ex-wmii user, I don’t see why you had to change the keybindings, unless you kept Mod1 as the default modifier. It’s very cool to change your desktop via 9fs (wmii2 FTW!), but soon it becomes a bit too tiring. So back to Blackbox again.
Please ignore.
Edited 2011-11-23 16:17 UTC
To add my tuppence worth;
I habitually use keyboard shortcuts where ever I can for GUIs (with a lot of mouse pointing to, certainly) and I would say that the advantage isn’t necessarily to do with speed, so much as rhythm. For anyone who spends most of their work time writing in one form or another, taking hands off keyboard and onto mouse feels like a break, rather than a continuation, of your work. Its generally faster to use the mouse (for me at least), but its less jarring to use the keyboard.
For the record, if you read the links I supplied what you, and others refer to with “feels like a break” unlike using keyboard shortcuts is a result of an Attentional Blink (https://en.wikipedia.org/wiki/Attentional_blink) where the cognitive retrieving of a keyboard shortcut causes you to feel like it’s faster, while the mouse, with no need for a cognitive retrieval of a shortcut feels slower.
“It is relatively unknown outside the OpenBSD community, but it deserves more notice.”
No it doesn’t. It’s looks ancient.
Edited 2011-11-25 10:29 UTC