June 2014 Linux Productivity Magazine: Light Weight, High Performance Computing

Linux Productivity Magazine

June 2014

Light Weight, High Performance Computing

Copyright (C) 2014 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Career skills nobody else teaches:

Books

Courseware

Editor's Desk

This Linux Productivity Magazine issue was originally scheduled to be a rant, and in researching that rant, I spent a week using the ultra-lightweight dwm window manager, augmented with dmenu, xxxterm, and just the right hotkeys for the way I work. My computer seemed responsive, with little latency. Each keystroke produce a result that I perceived as instantaneous. For want of a better word, my computer was crisp.

Then, in order to perform a diagnostic test, I briefly went back to my native Xfce, a desktop environment widely reputed to be "lightweight", at least compared to KDE, Gnome and Unity. After spending a week with dwm and dmenu, working with Xfce and its start menu and my beloved xfce4-appfinder felt like working in a swimming pool of molasses. Oh, programs ran just as fast. Once they got loaded. But it seemed like, with many tasks, I could actually count to three before the computer responded to my keystroke. This is on my daily driver desktop, a 2008 dual Pentium 2.53Ghz machine, so there's no excuse for "count to three" response time. Once you've experienced "instantaneous", "count to three" annoys you every second you operate the machine.

Oh, and my 2006, 2 core 64 bit AMD Turion laptop with 2GB RAM using dwm+dmenu+xxxterm is snappier than my daily driver desktop using Xfce+xfce4-appfinder+Firefox.

Responsive machines like I describe in this LPM issue aren't for everyone. They require remembering some keystrokes. They require a little practice. They use lesser-known programs, so you'll receive less assistance when troubleshooting or finding the best ways to mold them to your exact work style. Those who can't or don't want to learn are better off with Xfce or LXDE.

The setups I describe in this LPM issue are for those who feel the need for speed. Whether they're using an Intel i9 with 64GB RAM or a oldie with 256MEGAbytes of RAM, the response of these setups is crisper, and you can run more programs without bogging down. These setups take some getting used to, but if you're anything like me, once you try these setups, you'll never want to go back.

So kick back, relax, and read this issue of Linux Productivity Magazine. If you use computers, and use them hard, this is your magazine.

Retraction: Unity and Gnome3 Aren't Bad

In earlier versions of this magazine, I claimed Unity and Gnome3 were confusing to the point of unusability. I now retract any such statements.

At a Greater Orlando User Group Window Manager/Desktop Environment shootout on 7/2/2014, experienced practitioners of Unity and Gnome3 proved them to be highly productive in the hands of an experienced practitioner. I was wrong to call Unity and Gnome3 confusing junk. They're just a different paradigm that requires experience.

So I'll simply say this: Neither Unity nor Gnome3 is especially keyboard-centric, and neither is based on a hierarchical menu. So if you believe that, all other things being equal, keyboard interaction is faster than mouse interaction, you'll probably prefer more keyboard-centric Window Manager/Desktop Environments (WM/DE). Also, if you have a strong affinity to hierarchical menu systems and don't want to change, Unity and Gnome3 probably aren't the right WM/DE for you.

Both Unity and Gnome3 are big, heavy programs, so you need substantial hardware to run them. I'd say in 2014 that means 4GB of RAM, a >1Ghz processor, and a video card capable of all the necessary compositing and eye-candy.

But neither of these interfaces is junk. In fact, in the hands of the right person on the right hardware, they're very productive and fun to use.

Window Manager, or Desktop Environment?

If I call it a Window Manager, the guy I'm talking to corrects me and says it's a Desktop Environment. If I call it a Desktop Environment, the guy corrects me and tells me it's a Window Manager. Either way, the guy goes into a long, drawn out explanation of why he's right. A window manager, he'll tell me professorially, only enables windows to be moved, decorated, and interfaced with. A desktop environment, he pontificates, comes with applications to service your every interface need: a file manager, panels, applets, launchers, configuration programs, maybe applications for things like DVD burning, music playing and the like. And, as his coup de grace, the professor tells me that a desktop environment contains a window manager.

Stop it: It just doesn't matter. I'm talking about an interface, regardless of how many tools it has, or how integrated those tools are. And it's a spectrum, not a binary choice. Therefore it's a meaningless distinction. In the continuum between KDE on the integrated everything extreme, and Tinywm on the "just serve out windows" extreme, supposed desktop environment Xfce has no built in email, and supposed window manager Openbox has its own configuration tool. Lightweight supposed window manager Windowmaker has all sorts of applets and addons made to bolt right into it, as if they came with it.

The word "interface" is too generic to describe only the user interface presented by the operating system, so, for the rest of this magazine issue, I'll be calling these interfaces wm/de, for Window Manager/Desktop Environment.

KDE, or Gnome?

Can there be a more ubiquitous question in the world of Linux desktops? Which do you use? There are only two choices, right?

Oh wait, now there's Unity. And those Mint guys are always raving about Cinnamon and Mate. And thanks to Xubuntu and Lubuntu, we all are now aware of Xfce and LXDE. We have quite a choice, don't we?

Yes we do, and the preceding paragraph just scratches the surface, as you'll see by clicking the following link:

The preceding link opens a new tab in your browser, and I suggest you keep that tab open the entire time you're reading this LPM issue. The link is an excellent list of window managers/desktop environments, sorted by memory usage, small to big, made by a guy whose name appears to be netblue30. If you want to see the blog from which this list came, its URL is in the URLs section of this magazine.

Note:

For the rest of this magazine, I'll refer to the list of window managers, sorted by memory usage, as "netblue30's chart".

KDE Is a Special Case

If you use KDE and you're happy with it, that's great. The only thing is, I doubt anything in this document can help you work faster if you use KDE. My experience tells me that using the KDE wm/de, or even using apps that use KDE libraries, makes your computer krash happy and intermittently slow. A lot of people appreciate the close integration of KDE with its apps: That's definitely a feature. But other phrases for "close integration" include "non-modularity", "entanglement", and "lack of encapsulation", all of which usually lead to bugs very difficult to troubleshoot. They also often leads to sub-par performance, because the system design of entangled systems is so difficult that efficient algorithms are sometimes overlooked.

Every time I voice my opinion on KDE, I get lots of people telling me they've had nothing but good experiences with it. As the discussion progresses, invariably they tell me I've been using KDE on the wrong distro, and that if I'd been using distro X (usually Red Hat or Fedora), KDE would work great for me. I don't doubt it for a minute, but I have much more pressing priorities when picking a distro. If a wm/de doesn't work well with my chosen distro, I just don't use that wm/de. But all of this is beside the point.

The real point is that KDE is not a fast interface, and in fact it's a bottleneck to crisp performance. So it's unlikely you can use the suggestions in this document in order to work faster, other than possibly substituting a hotkey-instantiated dmenu launcher for KDE's graphical menu.

You Can't Get Fired For Using Xfce

The safe choice is Xfce. Add a menu button panel plugin, a windowlist panel plugin, and a notification area plugin to its default panel, make that panel the full width of the screen and not growable, and you have a Win95 like interface that anyone can use intuitively, and yet it doesn't gobble resources the way some other wm/de's do. Xfce isn't krashy like KDE, nor does it spawn huge processes and files the way KDE does. It's not confusing like Gnome3, Unity, Windows 7 and 8, and some of the wm/de's associated with Mint. You approach a reasonably configured Xfce, and if you have any Windows 9x or XP experience, you know exactly how to do whatever you need to do. Just for fun, associate a hotkey with xfce4-application-finder, and you have yourself a lean, mean, computing machine.

Upping Your Game

Xfce is a spectacular wm/de. Stable, reasonably fast, intuitive. Your Windows friends who have never used Linux in their life can sit at an Xfce-equipped computer and work with it.

Note:

Everything in the preceding paragraph is equally true for the LXDE wm/de, and LXDE is a little more stable and less resource consumptive. However, LXDE's slow mouse and inability to have multiple panels make Xfce a better choice for some people.

If you have Xfce or LXDE but want more speed and crispness, you can do it. You can up your game by making changes in the following broad categories:

About RAM

It would seem that in an era of commodity computers ranging from 4GB to 16GB of RAM, there's little distinction between a program that uses 10MB of RAM and one that uses 100MB. But it just seems that way. The truth is a little more detailed.

RAM accesses are neither instantaneous nor free. The more RAM a program's handling, the more time it takes reading and writing that RAM. The more work the CPU does maintaining that RAM, so that it's possible that RAM accesses could bottleneck the CPU.

Beyond all of that, there's a tendency for high-RAM programs to be more complex, and that complexity gives bugs a place to hide. The point I'm making is this: Don't assume 100MB here and 100MB there makes no difference on a machine with 16GB RAM. I view RAM like money: You gladly spend it when it buys you something you need, or it buys you a better product, but you don't spend it just because you have it. Spend it carefully. If something seems too RAM expensive for the functionality it gives you, look for alternatives.

Use Faster Applications

Firefox is a slow, bloated, bogdown pig. So is Google Chrome/Chromium, if you can even get it to work. I imagine Konqueror and Internet Explorer are slow pigs also, though I haven't used either in years. So why not switch to a faster browser?

Fast Browsers

There are tens of smaller footprint browsers. Some of them are quirky, crashy, or just don't work. Others lack features you need, and you can't get work around that lack of features. Some others do a bad job of rendering modern HTML and CSS. All of which still leaves several excellent browsers that will do your browsing and video for you. Use one of those.

My default browser is called xxxterm. Its name is slowly changing, on one distro after another, to Xombrero, but for the purposes of this LPM issue I'll use the word "xxxterm". No matter, this is the browser I use.

I still recommend installing Firefox for troubleshooting purposes, and so you can see the "correct" rendering of a website. If you can get your Firefox to run Youtube videos, then xxxterm will probably play those same videos, and play them better, with less stutters. xxxterm has tabs, and most of the other features you'd come to expect from a full featured browser. But it's much slimmer, quicker, and more stable. And you use the keyboard to operate it.

What I really like about xxxterm is it uses mostly Vim keystrokes, so I already know how to scroll up and down and how to search. Like Vim, you'll be underproductive in xxxterm until your hands learn the keystrokes. Like Vim, once your hands know the keystrokes, you'll operate it like greased lightning.

There's another lightweight browser, by the people who brought you dmenu, called Surf. Surf's lightweight, and it's simple, and it seems to play Youtube videos well, but from what I've seen, Surf is neither faster nor more efficient than xxxterm. Maybe that's because Surf uses Webkit to do all the work. If you decide to use Surf, be aware that you press Ctrl+g to enter a URL. To go back to the previously viewed page, or forward to one you came back from, you right click and choose from the menu. Once you have Surf running that far, your best bet is to search the web for Surf keystrokes and operations. Oh, and one other thing: Surf has no tabs, so if you want tabs, you run a program called Tabbed, a simple tabbed window, that puts one Surf browser in each tab. So you can have the simplicity of untabbed Surf, with tabs.

Surf's OK, but I find xxxterm many times faster than Surf because xxxterm has a much better keyboard interface, and backs it up with a mouse interface, so if your right hand is already on the mouse, you don't need to go back to home keyboard position.

Warning:

With both xxxterm and Surf, I found one huge (5.9MB), contrived graphic that caused the browser to grab control, not let go, locking the keyboard such that you couldn't do anything. After several minutes it killed the wm/de and brought me back to lightdm.

This is so rare that I'm calling it a warning instead of a danger, but if you ever load a page and the browser won't let go of the keyboard, don't load that page again in xxxterm or Surf, use a browser other than xxxterm or Surf to view that particular page from now on, and could you please email me with the URL of the page, so I can research it?

Fast Email Clients

Thunderbird is a bloated mess of a pig. It can take hours to synchronize with your IMAP server. The only time I use Thunderbird is for troubleshooting diagnostics.

Now here's the thing. All email clients suck. Some just suck less. If you enjoy a CLI email client on which you need to remember bunches of keystrokes, and you're willing to to DIY facilitate the SMTP-onramp function in order to use an email client that has no built-in SMTP-onramp, mutt is your client. If you want GUI and a little more integration, without the piggety of Thunderbird or the "I own your lifeism" of Evolution, you might like Claws-Mail. IMAP equipped, limited or no html, spectacular search facility, and just the right word-wrap facility. It has some disadvantages, but nothing that can't be worked around.

xxxterm Hotkeys and Tips

First, as shipped, xxxterm's search field doesn't work. Don't worry, fixing this will be explained later in this article.

xxxterm's convenience and speed comes from its keyboard interface. It has most of the usual mouse amenities, but if your hands are already on the keyboard, you can make xxxterm walk and talk and wheelstand. The following table shows xxxterm's most common hotkeys, and you'll notice more than a few of them come straight from vi/Vim:

Action	Hotkey	Comment
Refresh	F5	Occasionally doesn't work
Focus on URL	F6
Focus on search phrase	F7
Release all focus	Esc
Focus on first input field	i	Insert mode, quirky
Focus on next element	Tab
Scroll down	j	Vim navigation
Scroll up	k	Vim navigation
Scroll left	h	Vim navigation
Scroll right	l	Vim navigation
Go to top	gg	Vim navigation
Go to bottom	G	Vim navigation
Add to favorites	:favadd
Favorites	Alt+f or :fav
Number links	f	For keyboard link choice
New tab	Ctrl+t
Duplicate tab	F12	Conflicts with Openbox hotkey
Close current tab	Ctrl+w
Next tab	Ctrl+right
Previous tab	Ctrl+left
Search	/	Similar to Vim
Search backwards	?	Similar to Vim
Next occurrence, forward	n	Similar to Vim
Next occurrence, backward	N	Similar to Vim
Previous web page	Backspace
Undo Prev web page	Shift+Backspace

A few comments on the preceding keystrokes. If you want to "click" a web page's links from the keyboard, you just press f to number the links, and then input the number. If the number you enter is unambiguous (let's say the number is 19 on a page with 50 links), xxxterm takes you right to the target of the link. If the number you enter is ambiguous (let's say you enter 3 on a page with 50 links, then xxxterm doesn't know whether you mean 3 or 30 or 31, etc), you need to press Enter after entering the number. This is necessary mostly for single digit links.

Data loss danger!

The favorites list produced by Alt+f comes complete with an X link to the right of each favorite link, and if you click or enter the number of an X link, the favorite link to its left is deleted.

So when you enter favorites links numerically, you'd better get the number right, or you could delete one of your favorites.

Your truly valuable links should be somewhere other than xxxterm's list of favorites.

F5, refresh, once in a while does nothing. If you start to suspect that it's not doing its job, follow this list until something refreshes it:

You can use Insert (i) and Next Element (Tab) to fill out forms, but that can be quirky. I haven't yet gotten my field-fu down in xxxterm, but I'm sure once I do, I'll be able to whip right through web forms.

Duplicate Tab defaults to F12. F12 under Openbox opens the root menu. The Duplicate Tab function is extremely handy, so if you want to use it, you need to change the hotkey in ~/.xxxterm.conf. If you don't have a ~/.xxxterm.conf, make one. Here's how I changed my Duplicate Tab key from F12 to Shift+F12:

One more thing about the Duplicate Tab function. What it really does is write a command in the command area (you can manually do this by pressing the colon -- I told you if you know Vim, you know xxxterm). So after pressing F12 or Shift+F12 or whatever, you need to press Enter to run the command.

Configuring xxxterm

To get maximum benefit from xxxterm, you'll probably need to adjust its configuration. For instance, due to my bad eyesight I needed to change the default zoom level from 1.0 to 1.5. To get xxxterm windows to open in a useful size, I had to define them as 1080 width, 1000 height. As mentioned before, I needed to change the hotkey for Duplicate Tab to avoid conflict with the default root menu keybinding of Openbox, and as mentioned before, I had to change the search string in order to get xxxterm's search field to work. The following is my ~/.xxxterm.conf file:

A few words of explanation. The browser_mode setting must appear and it must come first. It can be either normal or whitelist.

More and more software is switching to zoom level rather than font sizes, for easy matching of the software to one's visual acuity. xxxterm does this with its default_zoom_level setting.

If you want newly run xxxterm windows to be maximized, you'd change window_maximize to 1. I keep it at 0.

The cmd_font property affects only the font for search and colon commands you input. The default is quite small, so you might want to make it bigger even if you have 20/20 vision. There's no real downside for making it big: If you're typing in a command, you're not doing anything else with xxxterm.

The window width and window height are how you want it to appear when it first comes up.

The search_string I've put in the ~/.xxxterm.conf is for Google, but you can input search strings for several other browsers.

And last but not least, I changed one key binding. In my opinion, xxxterm's key bindings are well thought out, especially for a Vim-familiar person, but in this particular case I had a conflict and didn't want to change the hotkey for Openbox, so I changed the one for xxxterm.

Learning More About xxxterm Configuration

As far as I know, there's no configuration utility for xxxterm, and I like it that way. I configure it with Vim.

But how do I know the right syntax to use on each line? Luckily, xxxterm ships with an example config file. On my system, it's at /usr/share/doc/xxxterm/examples/xxxterm.conf.gz, and it can be viewed with zless. Your mileage may vary. If you can't find it, do something like this:

Bottom Line

If speed is a priority for you, xxxterm is your browser. First, it's less bloated and less crashy than the usual suspects, so it's faster even if you don't take advantage of its keyboard interface. But if you really feel the need for speed, learning its keyboard interface enables you to run circles around your friends using Firefox, Google Chrome/Chromium, and Internet Explorer. Although xxxterm looks savage when you first see it, you can configure it to be good looking, readable, and handy.

Optimize Your Hotkeys

Every touch typist knows that the keyboard is twice as fast as the mouse. If you type over 30 words per minute, you want to do as much as you can from the keyboard. Especially if you're using a wm/de without taskbars or panels. But even on a mouse friendly interface like Xfce, keyboard shortcuts are quicker. And when you link those keyboard shortcuts to fast tools, you make that computer walk and talk.

Hotkeys can be confusing, especially because different wm/de's give you different ways to configure your hotkeys. First, read all the documentation for your wm/de: What config tool sets up hotkeys? What file(s) contain the hotkeys? What is the syntax of the hotkeys in the file? How do you set a hotkey to run an external program?

Note:

A wm/de that can't be hotkeyed to run an external program is useless. Luckily, well over 90% of the wm/de's I've used can assign a hotkey to run an external program, although the way to do so isn't always obvious.

A special problem comes up in hotkeying, time and time again. Sometimes keys aren't represented the way you think they would be. Take, for instance, the semicolon key. You would think you'd assign Shift+Ctrl+; to run dmenu_run like this:

Situation	Config
Openbox wrong	<keybind key="C-S-;"> <action name="Execute"> <command>/usr/bin/dmenu_run</command> </action> </keybind>
Openbox right	<keybind key="C-S-semicolon"> <action name="Execute"> <command>/usr/bin/dmenu_run</command> </action> </keybind>
JWM wrong	<Key mask="SC" key=";">exec: dmenu_run</Key>
JWM right	<Key mask="SC" key="0x3b">exec: dmenu_run</Key>

The preceding examples show that although using a literal ; seemed like a good idea, it just seemed that way. In Openbox you need a specific name, and in JWM you need a hex number. In both Openbox and JWM, the xev program is your friend. Run it from a GUI terminal like xterm or xfce4-terminal, make sure xev has focus, and type a semicolon on the keyboard. You'll see the KeyPress and KeyRelease events printed in the GUI terminal. Here's what the KeyRelease event looks like for semicolon:

Notice the keysym is given both as hex value 0x3b and as symbol semicolon? You use the hex value for JWM, and the symbol for Openbox.

Note:

I've had success using the names, as well as the hex values, in JWM. Just be sure to type it exactly as you found it in xev, including the case of each letter.

wm/de Hotkeys I Use

I've developed a set of hotkey assignments that I use on Xfce, Openbox, JWM, and to the extent possible dwm. If you use these hotkeys, you can rename your computer "Lightning", because that's how it will perform.

Hotkey	fcn/pgm	Comment
Shift+Ctrl+;	execute dmenu_run	Quick KBD driven launcher
Shift+Ctrl+,	root menu	"Start Menu"
Shift+Ctrl+.	client-list-combined-menu	List of windows, by workspace
Shift+Ctrl+h	Workspace left	Vim like
Shift+Ctrl+l	Workspace right	Vim like
Shift+Ctrl+j	Workspace down	Openbox: Shows current workspace
Shift+Ctrl+k	Workspace up	Openbox: Shows current workspace
Alt+<digit>	Go to workspace	Alt+4 goes to workspace 4, etc
Ctrl+9	execute Umenu	Or whatever external hierarchical menu you choose
Alt+0	Close window	Much easier than Alt+F4
Alt+Space	Window menu	If not already default. Note that on dwm this keystroke toggles between Tiled and Monocle layouts.
Alt+Tab	Cycle thru windows	If not already default. JWM windows don't cycle as expected.

The preceding isn't a particularly long list of hotkeys, and every one of them does something you do several times per day. Moving between workspaces, finding what workspace you're on, searching all workspaces for a running program, drilling down hierarchically from the root menu to run a program, using a keyboard-driven launcher (dmenu_run) to quickly run an app, invoking a window menu, and closing a window. These are things you do five to 100 times a day.

Notice that no hotkeys are wasted on seldom used tasks. No hotkeys to move a window to a different workspace: Most people don't move windows to other workspaces that often, and the window menu performs that functionality quick enough.

Note:

dwm is an exception to the preceding paragraph. Windows in dwm have no window menus, so a "move to workspace" hotkey is essential for dwm.

Notice that no hotkeys are wasted on tasks easily done other ways. There are no hotkeys for running individual applications: dmenu_run makes quick work of that. There are no wm/de hotkeys for things that can be done from a window menu.

Notice the hand position of most of the hotkeys. Many involve hitting Ctrl+Shift with the left hand, and an easy right-hand letter with the right. From home position on the keyboard, pressing Shift with your right ring finger and Ctrl with your right pinky is trivial, and it's trivial to quickly snake your way back to home position afterwards. And these Ctrl+Shift hotkeys are unlikely to conflict with default hotkeys on other software.

Several of them, such as the Workspace Left and Workspace Right, are already muscle memory to the hands of a Vim user, so it's totally natural.

Note:

If you want to implement these keystrokes on the dwm wm/de, you'll need to actually change the source code in dwm's config.h file, and them recompiling it. This isn't as hard as it might seem, but it's not as easy as changing a config file, either. Naturally, back up your original config.h before changing it.

Bottom line: These hotkeys are lightning fast, easy to use, and easy to make into a habit. If you're a touch typist, you can use these hotkeys, plus tools discussed later in this document, to turn your computer into a racecar.

Use Faster Tools: dmenu

Of all the available tools, nothing speeds up my work in a GUI wm/de more than the dmenu collection from the suckless_tools package. There are two reasons for this huge speed increase:

dmenu_run

Of all the launchers in the world, my favorite is dmenu_run, from the Suckless Tools package. It springs to life instantly, offering every program on the path, displaying several of them, with the touch of a hotkey. Then, as you type characters, the choices narrow to those containing the string, with commands starting with that string coming first. You can usually start the desired program with five to seven keystrokes, including the hotkey that started dmenu_run.

dmenu is a filter, taking input from stdin and outputting to stdout. To be more specific, it takes a list of items, one per line, on stdin, presents them to the user, and once the user has chosen one by pressing Enter on that one, dmenu outputs the chosen text to stdout. To see it in action, do this:

After running the command, look at the very top of the screen to see the menu. It very thin, and not an especially readable font/color combination. Don't worry about that now, you can change its appearance later. Just type b then z to narrow the list, and then use the arrow keys (if necessary) to get to bzcat and press Enter. Control returns to the terminal on which you typed your command, and you'll see your chosen string in front of your normal command prompt. That's the string returned via stdout, without a newline at the end, as shown in the following session:

Now type f, then i, then r, then e, then f, and notice how the number of choices is reduced with every letter, until eventually you can either use the arrow keys to select the proper one, or keep typing characters until it's uniquely identified. Most of the time, because home typing position is so much more efficient than reaching for arrow keys, it's faster to type the name until the desired program is the first one, and then press Enter. When you press Enter on firefox, Firefox runs, and you see Firefox stdout messages on the terminal on which you ran the command. When you terminate Firefox, control returns to the terminal on which you ran the command.

If you ever decide you don't want to select anything from the menu, just press Esc, and control returns immediately to the terminal. Unfortunately, it doesn't return 1 (for failure) when the user escapes out of it, but don't worry, we'll soon fix that, and once it's fixed, you can use the dmenu system to front-end just about any kind of computer program you want.

The dmenu_path program does nothing but return a sorted list of every executable file on your computer's $PATH. When you pipe that into dmenu, you can choose from every executable your computer has on the execution path.

dmenu_run is a shellscript to pipe dmenu_path into dmenu and execute your choice. The following is dmenu_path as it ships from suckless_tools:

If you look at the preceding code for a couple minutes, you'll see what it does. I think the ${1+"$@"} thing just turns all the arguments of dmenu_run into a single string. The preceding returns 1 if the user escapes out, and 0 if the user runs a program, so it can be used in all sorts of scripts and to front-end all sorts of programs.

Looking at the dmenu man page, you'll see it has all sorts of command line options to change the appearance of the output. You can adjust your dmenu script. The following is how I adjusted mine:

In the preceding, I set the font (-fn) to a bigger size (12x24), set selected item colors to yellow on blue, set the others to white on black, set it to display vertically instead of horizontally (-l), and set it to display 36 lines (-l36). I also set it to case-insensitively match the text I input (-i).

Bottom Line

No matter what wm/de you use, no matter what software you use, regardless of almost anything else, if you assign an easy hotkey to dmenu_run, your computer usage is going to get much, much faster. dmenu is insanely fast: It searches $path, sorts, and displays the results almost instantly. As you narrow the list of choices by pressing keystrokes, the shrinking of the list happens faster than you can perceive. It can be used from the command prompt to run CLI programs, or from a hotkey to run GUI programs. It can even be used to build yourself a special application, or to bolt a user interface onto a simple executable.

No matter how you run your computer, if you're using Linux or BSD, you should add dmenu to your interface!

Switch to a Different Wm/de

Once again, take a look at http://l3net.files.wordpress.com/2014/02/cmp-all4.png, and contemplate the fact that the world is your oyster. You have many, many wm/de's to choose from, and a lot of them are excellent. I've already said that here at Troubleshooters.Com, you can't get fired for using Xfce. If I were stranded on a desert island and could use only one wm/de, I'd use Xfce. I use Xfce for my kids every time: I don't need any more family instigated tech support. But me, I want to up my game.

So many great wm/de's, so little time. In later articles I'll discuss these four champions:

If a wm/de can accommodate your choice of hotkeys for any window manager functionality and/or any random executable, the wm/de is going to be productive for you. On the other hand, if a wm/de can't assign your choice of hotkey to whatever window manager function or executable you want, it's not worth the time it takes to install it. The good news is, more than 90% of the wm/de's I've tried easily accommodate your choice hotkey/function/executable combos.

dmenu is wonderful, but sometimes you don't know the name of the program you want. That's when a root menu (start menu) comes in handy. With a root menu, you can pick a category, then a subcategory, and continue drilling down until you've picked a program whose name you didn't know in the first place.

All root menus are not created equal. A good root menu is fast. Whether you're using the keyboard or the mouse, it needs to be fast. If you need to press Enter or left click on every item in order to go to the next level, like in Windowmaker, that's not fast. The best root menus display the submenu of an item when you hover the item, or when you cursor down to it. Extra points to root menus that move to a choice based on letter keystrokes, like Openbox.

Always make sure that you have multiple wm/de's installed and runnable on your computer, so if you accidentally mess up one, you can switch to another and fix the damage. If somehow you get so messed up you can't get a wm/de up, but X is still working, just go to a CLI terminal, Ctrl+Alt+F3 for instance, and perform the following command:

By the way, it should go without saying, but always be sure to back up your wm/de's config file (or in the case of dwm, config.h) before changing it, so you can "put it back" if your experiment doesn't go well.

Lesser Known Wm/de's: The Challenge

If you use KDE, Gnome, Unity, Xfce or LXDE and run into trouble, you can get tons of help online, both from web searches, and from mailing lists and the like. If you're using Openbox, dwm, or especially JWM, such information is hard to come by. If you use Openbox or dwm, I have a couple IRC channels for you. They don't seem very responsive, but at least they're well populated:

wm/de Compensations

Thinner wm/de's perform well, but they require you to change some of the programs you use and change some of the habits that you've formed. Most of these changes are almost trivial to make, if you know what to do.

Short, Distinctive Names

Using Xfce, it's easy to let the start menu do all the work. However, once you begin depending heavily on dmenu_run, the need for speed requires that commands you use frequently have filenames that are distinctive within the first few characters. For instance, to specify xfce4-terminal using dmenu_run, you'd need to type xfce4-termi, because there are over ten programs beginning with xfce4-, and there's a program called xfce4-term, and it's probably faster for the touch typist to type the all 11 letters than to move to the cursor keys. And obviously, typing a hotkey plus 11 characters plus Enter is no way to work fast. So here's how you solve this problem:

Now, when you run dmenu_run with a hotkey, you can uniqely specify it by typing xft

Do this for any long-to-specify commands you use often. Also, what I do, and you might like this too, is I make the symlinks in a directory owned by user slitt.

Touchpad Mouse Toggle

This is actually a necessity on all laptops, because if you're doing serious typing, the mousepad will mess things up, so it's usually better to have it disabled. And yet sometimes you might need the mousepad. So make the following shellscript, permissioned executable, and either put it on $PATH and call it ttog, or hotkey it:

My personal preference is using a fast hotkey (Shift+Ctrl+j comes to mind), so that the switch can be made lightning fast.

All Workspace List

One of the coolest things about Openbox is the list of windows, sorted by workspace, that gets displayed with a mouseclick. On Openbox, I connect hotkey that to Shift+Ctrl+period. Other wm/de's don't have that facility, but at least you can use Suckless Tools' lsw command to get a window list, although it doesn't sort by workspaces. If your wm/de doesn't have a built in window list, try making your own, called wls, and perhaps hotkeyed to Shift+Ctrl+period. Here's one based on lsw:

Shut Off Screen Blanking

You change wm/de's, and all of a sudden your screen goes black after a certain time. Sometimes you want that to happen, to lessen power drain. But other times you don't. Before I give you the solution that worked for me, read this and this. Then, check out my noblackout.sh script:

Networking Without Panels

nm-applet is wonderful, until you use a wm/de without a panel. Then what do you do? You might be able to find a network-manager front end that doesn't depend on a panel, but I haven't found one yet. So I switched to the wicd system. I installed the daemon, the GTK client, the CLI client, and the Curses client. So, as long as the daemon's running, I have many ways to access the network settings, without the need for a panel.

I set up the following shellscript, called wiccd.sh, starts the daemon and then starts the GTK client:

The xterm is necessary so you can input a password. Please note that the wicd daemon will fail if /etc/resolv.conf is a symlink. So if it's a symlink, remember the name of the real file, delete the symlink, and then copy the real file to /etc/resolv.conf, making permissions and ownership of /etc/resolv.conf the same as the real file.

Notifications

Notifications are the little notes in the upper right corner when your Internet radio station switches songs or when a print job finishes. Personally, I'd recommend using the notification system that came with your wm/de. However, some wm/de's don't ship with a notification system, so you need to install your own.

No problem, install Dunst, the lightweight notification tool, available as part of the j4tools tools set:

When setting up and testing Dunst or any other notification system, be sure to use the notify-send program to send test notifications. Read the man page for notify-send to see all the options, including priority.

Panel

"Panel" is Linux-speak for taskbar, that thing Windows had from Win95 through Windows 7: One of the few things people liked about Windows. If you've used Windows 8, you might think lack of a panel ruins your computer experience.

Note:

Yes, I know, I know, Windows 8.x has a taskbar in one of its two modes, but unless you're comfortably familiar with Windows 8.x, a lot of times you can't find your way to that mode, so sometimes it's no different from not having the taskbar at all. And of course, they changed the way to get to it between 8.0 and 8.1.

In my opinion, if your wm/de doesn't contain its own panel, it's probably best to leave things that way. Panels decrease screen real-estate, increase your reliance on a mouse, and bloat your computer. Like an order of magnitude more memory, both memory allocated and memory used, than dwm. See the following ps commands to see what I mean:

Panels are pigs! On wm/de's not having panels already, add a panel only when absolutely necessary. And make sure you're in a position to close them once you're done with them.

Viewing System Status

One of the great contributions of a panel is for seeing system status: CPU usage and frequency, battery status and CPU adapter. This might seem like a job for gkrellm, but it only seems that way. gkrellm has its own sizing information, and pays little attention to the window manager: A real problem with a tiling environment like dwm. So, instead, I suggest you devote one workspace (tagset for you dwm guys) to system info and the like.

On that workspace, have one terminal window running htop, to give you your CPU and memory usage, and the apps consuming them. On another terminal window, have the following shellscript running:

Between the preceding script giving you battery and AC adapter status, CPU frequencies, time and date, and htop giving you CPU and memory usage, you have pretty much every system indicator you had on your old panel. If you want CPU temperature, add in a client for lm-sensors, either as part of the preceding script, or as a brand new window on your status workspace.

If the preceding sound difficult, especially viewing windows, keep in mind that as you get used to working without a panel with window buttons and the like, your housekeeping will vastly improve. You'll start to close windows you don't need anymore. You'll start to use specific workspaces for specific things, and clear them off when you're done.

If you MUST Have a Panel

Almost always, an alternative work habit can compensate for lack of a panel, and have you working either faster, as fast, or almost as fast as using a panel. If you consider a panel to be a must for everyday work, you'll be happier with a wm/de with a packaged panel, such as LXDE, Xfce, or low-RAM wm/de's JWM and IceWM or a host of others.

But there's another situation: The need of a panel once in a while, such as in the following situations:

In the preceding rare situations, it makes sense to temporarily run a panel, to get access to the root menu and other seldom needed things. Keep in mind that some window managers, such as dwm, treat the panel as just another program, so it can be run with dmenu and closed with your Close Window command.

In such cases I'd recommend lxpanel, because it uses less RAM and less screen real estate than xfce4-panel or even the supposedly minimal fbpanel. Better yet, you can configure lxpanel take up a very short space, and put it where it won't be obtrusive, like in the upper right when using dwm.

Note:

lxpanel is just another program that can be closed by the window manager on dwm, but on Openbox it's a real panel that stays on all workspaces until you kill it. Therefore, when you temporarily run lxpanel, run it from the command line of a terminal. That way, you can kill lxpanel with a Ctrl+C keystroke on the terminal running it.

Wine

Wine is much easier to use with a panel and start menu. I don't yet know how to compensate for this without panels and start menus. In such situations, you might want to temporarily run lxpanel and then close lxpanel when you're done with your Wine activities.

Also, there are ways to run Wine apps without a root menu: They just require convoluted commands.

Fonts

By default, Linux doesn't handle fonts very well. Typically, you need to do quite a bit of finessing to get your GUI fonts to be dark, non-pixellated, correctly sized, and readable. KDE, Gnome and Xfce give font assistance, so that you don't need to finesse them yourself. But when you start using the lighter wm/de's, you're back to finessing your fonts into readability. For those with 20/20 vision, this probably isn't even in an issue. For those with less visual acuity, it might be.

Linux fonts is a very complex issue, depending on how you started X (xinit, xinit, or one of the lightdm type starters), as well as your wm/de config, and configs for the GUI library from which the application was built (gtk, Qt, etc). If you have any GUI font tips, please email me.

Handy Tools

Here are a few handy tools, whose man pages explain the details, for dealing with fonts at the X level:

Litt's Font Tips

Beware of the Easy Way:

You can run xfsettingsd, as root, and change appearances with xfce4-appearance-manager, and this will give you better fonts and more control, but be aware that xfsettingsd uses several times more RAM than dwm itself. If you're trying for crisp, responsive performance, it's usually best to save your RAM for applications that truly require it.

More authoritative information than what I'm writing here abounds on the Internet. My reason for including these tips, which will probably work for some readers but not for others, is to put all these suggestions into one place instead of having it all over the net. In my opinion, you configure your fonts on several distinct levels, in approximately the order that follows:

This discussion assumes that you've moved from a wm/de whose fonts satisfied you to one whose fonts don't, so that your fonts were once set up well, and you just need to make them behave like they did on the other wm/de. In that case, you're looking for, among other things, universal adjustments.

X level

Some font settings reside in X itself. In general, these effect everything not overridden by one of the other levels.

First things first: Find out what your "natural" dpi setting is with the following command:

If you have one or the other, symlink the other one to the existing one so you have both and they're guaranteed the same. If you have both, I'll explain that in a minute.

If, after following the advice in the preceding couple paragraphs, you have one real file and one symlink, edit the file (either one) and insert the following at or near the top, keeping in mind that an exclamation point is a comment:

If your .Xresources and .Xdefaults are both independent files, then add the preceding config lines to both of them.

Note:

My setting of Xft.dpi to 108 in the preceding config is because of my bad vision. My computer's natural dpi is 96.

A few words of explanation: Nominally, your Xft.dpi should be the value delivered by the xdpyinfo | grep resolution command. However, if your vision is very bad, I'd advise you (in contradiction to David Dusanic) to raise the number by up to 20%. As you start getting toward that 20% mark, you'll see windows with text outgrowing its tabs and decorations. However, increasing this number is the single easiest way to make everything on your screen bigger, regardless of the myriad of other settings for wm/de's, libraries, and individual applications. Also, if you change wm/de's and all of a sudden all the print looks smaller, this could be a way to bring back the size with one fell swoop.

You probably wondered why I had you make both .Xresources and .Xdefaults. It's simple enough: Depending on how X is started, whether xinit, startx, lightdm), or various other ways, different files could be consulted. Having both these files maximizes the likelihood that your desired X settings will be respected regardless of how you started X.

Remember, your settings in .Xresources and .Xdefaults tend to affect everything in your graphical user interface, unless something else overrides them.

Wm/de level

Xfce uses xfce4-appearance-settings, LXDE uses lxappearance, Openbox uses obconf as well as file direct editing of file ~/.config/openbox/rc.xml. JWM uses direct editing of file ~/.jwmrc. With dwm, you configure the few variable Window Manager fonts by editing your config.h file and recompiling.

Wm/de level font settings tend to affect mainly wm/de implements like taskbars, trays, etc, and window decorations like the title and the menubar.

GUI library level

The GUI library level configs tend to configure fonts in the window decorations, the window menus, and other such artifacts. The client areas in which you input information are usually controlled by application level configs. The exception is things like file managers, where basically the whole thing is output.

Sounds simple in concept, but it can be a mess! You see, different distros do different things at the library level. Computers have all sorts of minor unexpected behavior dealing with library configuration. And instructions written on the web reflect these differences. The instructions on the web likely won't work for you, or won't work on some of your computers.

Meanwhile, when you want to change an app that has tiny fonts, gargantuan fonts, or cookie crumb pixelated fonts, you need to find out whether the app is gtk2, gtk3, Qt3 or Qt4, and then do the proper thing. And naturally, if you use a helper program like lxappearance or qtconfig, unexpected things happen. It's a mess, and all I can do is give the advice that has worked for me. Which may, or may not, work for you.

Your First Job

Your first job when trying to fix the fonts on a program is to find out what libraries it uses. For example's sake, perform the following command to find what libraries thunar, a frequent source of font frustration, uses:

The preceding shows the program to be a gtk program, almost certainly a gtk2 program, evidenced by x11-2.0. Now do the same thing with Bluefish:

The preceding shows Bluefish to be a gtk3 app. Now let's repeat with the music player program Clementine:

Armed with knowledge of which version of which library an app uses, you can eliminate a lot of trial and error.

gtk Font Tweaks

Look at the Internet, and you'll see scads of conflicting info on tweaking gtk fonts. The number of files mentioned is almost endless:

It Sounded Like a Good Idea At the Time

And of course, everyone and their dog has the following example code:

style "schrift"
   {
   font_name = "DejaVu Sans 10"
   }
widget_class "*" style "schrift"
gtk-font-name = "DejaVu Sans 10"

Best of luck with that: It sure didn't work for me. And I'm pretty sure that "schrift" is no kind of reserved word, but just the German word for "font", and if that's true, I sure wish the examplers would make that clear.

I have no doubt that the person who really understands gtk would be able to make sense out of all the noise on the Internet, and explain which contexts call for which recommendations. But if you're anything like me, gtk is just a means to an end, and you don't want to get that personal with it.

So here's what I recommend: Instead of going through all that trial and error with various syntaxes in a multitude of file alternatives, use lxappearance to change the appropriate files. Sometimes it silently fails to change the files, but often it writes exactly what's needed to exactly the right file(s). If it silently fails, make sure the appropriate files are permissioned for write and don't have an i extended attribute. The beautiful thing about lxappearance, and what makes it much better than xfce4-appearance-settings, is that it needs no daemon: All lxappearance does is change the right config files in the right way, and as far as I know, it simultaneously changes both gtk2 and gtk3 settings.

Qt Font Tweaks

If ldd shows an app as Qt 3 or 4, you change its font by changing Qt settings. If you can find out where Qt config is stored, you're a better researcher than I. So here's what I do...

I install the Qt4 configuration utility. On Debian the package is called qt4-qtconfig, which installs two executables:

Obviously, qtconfig-qt4 adjusts Qt4 configuration. qtconfig adjusts Qt3 apps. But it appears to follow whatever you set in Qt4. But Qt3 apps don't get the message.

By the way, if for some reason your qtconfig-qt4 or qtconfig doesn't work, try your best to fix it, because I was unable to find a manual method to change Qt app settings.

Application level

On well made applications, the application level font settings control all text in the program that isn't a window title, a window menu, part of the menubar, or a write-only status output. On such applications, you can compensate for bad fonts, at least in the areas in which you type. Each application has its own font configuration facility, so look in the application's help facility to figure out how to do it.

Locking Your Screen

When you step away from your computer, you should lock your screen so nobody can mess with your computer. Several programs do this, but most of them leave your screen black, so upon returning to your computer, you don't know whether it went black on timeout, whether it crashed, or what. It's nice that nobody can read your screen, but personally, I'd like some indication that I need to type my password.

I'd suggest you install and use i3lock. At a minimum, it has a unique way of acknowledging keystrokes, so the first time you hit the backspace key (or any printable key), you know you're not hung, i3lock has taken over. Better yet is i3lock's -c (color) option, where you can specify an rrggbb hex color ID. Best is the -i (image) option, with which you can specify a .png image to uniquely identify a screen locked with i3lock. The following is my i3lock.png, which I created and now place in the public domain:

The following is the command I use to invoke i3lock with that lock graphic and a very dark blue background that won't burn a lot of battery:

There's a lock called xtrlock, that leaves your screen visible and changes the mouse pointer to a little picture of a lock. I recommend i3lock over xtrlock because with xtrlock, for privacy you need to switch to an unused workspace before running it. But anything's better than these blackscreen, "what happened?" screen locks.

Danger Will Robinson!

Don't use lxlock. When run on some non-LXDE wm/de's, it appears to kill X and gives you no opportunity to type your password.

dwm

Toto, I don't think we're in Kansas anymore! netblue30's chart lists dwm as using 1MB of RAM. That's 1/7 the RAM of Openbox, 1/36 the RAM of LXDE, and 1/70 of Xfce's RAM usage. No window menus. No titlebars with their close, maximize, minimize and shade icons. No window decorations at all, unless you count the almost impossible to see border that supposedly identifies the window with focus. Not having found that border, I need to look up at the amazingly thin status bar on top to see the name of the program with focus.

Note:

I've since modified my dwm so the focused window has a 3 pixel bright red border, so now I can identify who has focus at a glance.

The following is a dwm screenshot, and to see it full-sized just left click on it:

The preceding screenshot was made in dwm's tiled layout (I'll later discuss dwm's three layouts and how to switch between them). On the left is the source of this magazine in Bluefish, on the right right is the page as it appears in xxxterm. You'll note that neither has any window decorations: No titlebar, no border, at least that I can see. If you click the graphic to see it full sized in your browser, you'll see the skinny blue status bar at the top, listing tagsets 1 through 9, with 2 highlighted (meaning I'm currently looking at tagset 2), and tagsets 1, 2 and 9 decorated with a tiny square, meaning there are windows assigned to those tagsets. For the time being, think of tagsets as workspaces or desktops: They're not, but you can use them similarly.

To the right of the list of tagsets is the title of the window with focus. Supposedly the focused window has a border around it, but I can't see that border, so any time I don't know which window has focus, I look up at the status bar. Incidentally, the reason the title on my screenshot says "jwm_screenshot.png" is because, at the moment of the screenshot, a third window, xfce4-screenshooter, titled "jwm_screenshot.png", actually had focus, but it vanished before the snapshot was taken (if that makes any sense).

The Elephant In the Room

Before going on, let's discuss the elephant in the room: dwm has no config file. If you want to change colors, or fonts, or change the numbers or names of tagsets, or key bindings (and dwm's default key bindings suck), you need to edit config.h and recompile. Some people just don't like that.

The Genius of dwm

dwm is alone in all the wm/de's I've ever tried in that it can switch between tiled layout and monocle layout with a single hotkey. Tiled shows all windows, Monocle shows just one that covers the entire screen, and you can toggle between the two with Alt+Space, or press Alt+T for Tiled, or Alt+M for Monocled. I'm not going to cover "Floating Layout", because I think floating layout is lame in dwm, slows you down, and if you want floating, just use Openbox.

Anyway, in tiled layout, one window takes up the left half of the screen, and all the other windows are stacked up on the right half. See the following screenshot:

As you can see, Bluefish is the big window on the left, with the right side containing a stack, starting from the top, of:

Here's the way it works. If the big left window is focused, then pressing Alt+Enter switches that window with the window at the top of the stack. However, if one of the stacked windows has focus, then pressing Alt+Enter swaps the big left window with the focused window.

Another piece of dwm greatness: It respects your screen real-estate. There's no panel to consume space. Of course, a lot of wm/de's go panel-less. dwm goes the extra mile by not showing window ornaments like the titlebar and the extra-thick border. When you're tiling five or six windows, those titlebars add up. Beauty is in the eye of the beholder, but when I look at a tiled dwm interface, it seems happier than others. There's a lot of white. Even my wife, who is much more aesthetic than I, said it looks nice.

With dwm, you don't spend a lot of time moving windows around. Alt+Enter switches apps between the big window and the top of the stack, or between the focused window and the big window. Need even more room to roam? Use Monocle Layout, and the app you're working on covers the whole screen, except for the 20 px bar at the top. If you're a fan of Windows 8's "Metro Apps", you'll love dwm's Monocle layout.

Sometimes, the fact that dwm is such an unknown means that, in many low-security situations, you can leave your computer long enough to go to and from the drinking fountain, without locking your system, because it's likely your coworkers don't know enough hotkeys to manipulate your system.

Yet another beauty of dwm: Its source code is clean and clear. The config.h file is a work of art, looking more like a configuration file than C source code. I'm not saying I understand all of it: dwm's programmer is much better than I. But I understand enough to see that he's using data centered programming, with data structures for monitors, windows (he calls them Client) that adds lots of other info to the traditional window ID. There's a font structure, a keystroke structure (Key), a Layout structure containing a char pointer symbol and a pointer to a function, and a Monitor contains an array of two Layout pointers.

To really understand the code, you need to start tracing around and understanding code like this:

The challenge of the preceding code is keeping in your head the relationships between all the data parts. The benefit of the preceding code is that once you know the data relationships, the code becomes as simple and modifiable as window manager code can be. Look at config.h and dwm.c. They really are things of beauty.

One more cool thing about dwm, and I think every Apple Fanboy could appreciate this, is how you look using it. Even the most clueless passerby knows from a momentary glance at your screen that you're using something very different, especially if you're in tiled layout. Instead of the helter-skelter of over-decorated windows everyone else has, your screen is nothing but apps, attractively laid out so that every square millimeter of the screen is optimally used. Like this:

Default dwm Hotkeys

Installing dwm From Source

If you're actually going to use dwm on a regular basis, you're going to want to modify it to your liking, and that means you're going to change the config.h file and recompile. And that means you're going to need to install dwm from source.

The instructions in this article are for initial installation, involving several steps besides compilation. And, in this installation, you modify no source code: You do that later.

Install Development Packages for xlib and xinerama

Be sure you've installed the xlib headers, meaning libX11-xcb-dev or something like that. dwm must have not only Xlib, but its header files (the development package). dwm cannot work without the Xlib package and its headers (development package).

If at all possible, install Xinerama with the Xinerama header files, probably called something like libxinerama-dev. If for some reason you can't install libxinerama-dev or for some reason you still get Xinerama-based errors, there are workarounds, such as undeffing XINERAMA, or commenting out a few things in dwm.c, but if you can install Xinerama and its development package, that's by far the easiest route.

Grab the Source Tarball

Go to http://dwm.suckless.org/, look for the link in the "Download" section that says "dwm 6.0", and download it in the usual way of your browser.

Untar the Tarball

Find a place to untar the tarball and untar it. My tarball created a single directory called dwm-6.0 with all the stuff under it, but rather than counting on that, perhaps the safest way is to create an empty directory, cd to that directory, untar it there, and then move dwm-6.0 wherever you want it. I chose to put it in my home directory, for reasons you'll read later.

Note:

When you first untar the tarball, there's no config.h file, only a config.def.h. Do not modify config.def.h, that will screw up everything. You must build a default, working, dwm before you customize it.

Check config.mk

Verify that config.mk is reasonable, which involves making sure you have a /usr/local/bin in your filesystem, and verify that config.mk's declared paths to minor dependencies are correct.

make clean install

Do this step logged in as yourself, not root. If you later want dwm installed in /usr/local/bin or something like that, you can later do this compile as root. But while you're modifying and compiling to make dwm just how you want it, it's safer and a lot less work to do this step logged in as yourself. Understand that when compiling logged in at yourself, the make command throws errors while trying to copy files to the /usr/local tree.

Logged in as yourself, in the directory containing config.def.h, config.mk, dwm.1, and dwm.c, perform the following command:

If your life is anything like mine, the preceding command shows you a warning about "XKeycodeToKeysym is deprecated", which is normal, and an error stating that "cannot create regular file /usr/local/bin/dwm: Permission denied", which is exactly what you expect given that you compiled it as yourself and not root.

You'll know the compile was successful if it created the all-important config.h file and the executable dwm file, both with filedates coinciding with the time you did the compile. If you didn't get the expected results, troubleshoot exactly like you would with any other compile. Look at messages, see if your computer has missing packages.

Back Up and Symlink the Original dwm

If you start X with a display manager like lightdm, lxdm, kdm, gdm, xdm, and the like, then you actually need to have an executable or a symlink called dwm, in the directory that the display manager expects it, typically /usr/bin for most distros. Display managers typically ignore the contents of ~/.xinitrc, where you'd put the wm/de executable if starting X with startx, or xinit.

All distros I've seen allow you to use a display manager, but a few force you to use a display manager (cough, cough, Ubuntu). If you're using a display manager, you will have needed to install dwm through the packaging system first, in order to make the display manager know about dwm and list it as a possible desktop. OK, fine, you'll play their silly game. You'll back up the package manager provided dwm, and then symlink dwm to the one you just compiled. Assume for this document's purpose that you compiled in /home/myself/dwm-6.0. In that case, do the following as root:

After performing the preceding commands, the next time you log out and log in, you'll be using your compiled dwm. Better yet, from now on, every time you compile, logged in as yourself, the dwm you see after logging out and logging in again is updated according to the changes you made just before compiling.

Decide: User or Root Installation

If several users will be using dwm, and they'll all be using the same dwm, you probably want to go with the root install, where the executable is installed in /usr/local/bin. However, if you're the only one using it, or if everyone's going to be using different dwm configs (which means different executables), then you want to do a user installation. The difference is pretty much whether you compile as root or as your own username.

All other things being equal, I'm a big fan of user installation. Having make install copy lots of files into who-knows-where always makes me a little nervous.

If you decide to do a user installation, you're done. If you want a root installation, repeat your compile as user root, and re-symlink to the new file:

A Few Final Thoughts

It's vital to get a working, factory fresh dwm running before you begin to customize it. Now that your straight-from-the-factory dwm is running, changes are as simple as modifying config.h and recompiling:

Assuming you compile as the same user you symlinked for, once you successfully compile, all you need to do to view the results is log out of dwm and log back in.

Rolling Your Own dwm

OK, can we talk? If you've used dwm for more than ten minutes, you know many of its hotkeys are just plain stupid. Alt+F for floating layout? Umm, that just broke the Alt+F hotkey used to invoke the File submenu menu in just about every program. And their existing Alt+Tab, instead of doing the normal thing and cycling through all the windows on a tagset (dwm equivalent of a workspace), toggles between two tagsets, and if you can think of a good use for toggling between two tagsets, you're smarter than I. dwm's default hotkey for doing what most wm/de's do with Alt+Tab is Alt+j, which, when done one-handed, is a wrist-twister the authors of Emacs would be proud to have created. And it's not just hotkeys. The border signifying the focused window is one pixel and subtly colored, so it's nowhere near obvious enough to glance and understand who has focus.

The horrors of this article's first paragraph are nothing that can't be fixed with twenty minutes modifying config.h and recompiling, and you don't need to know much C to do it, because config.h is laid out for easy change by example. Just make sure to do the following:

The following is a list if changes I made, in order to elevate dwm from wrist-twisting confusion to almost the wm/de of my dreams:

Because Ubuntu is "startx verboten", requiring lightdm and Plymouth and all that noise, the only way I could run my newly compiled dwm was by renaming /usr/bin/dwm to /usr/bin/dwm_ubuntu, and then making the following symlink as user root:

Dwm In a Business Environment

Yes, you did read this article's title correctly: "Dwm In a Business Environment"!

I can see the followers of Gates and Jobs covering their ears to block out this blasphemy. After all, Gates and Jobs long ago won their propaganda war, proving for all but the most hard-core optimists that people are just too stupid to use any machine whose interface isn't instantly obvious to an eight year old. If they hadn't won that war, we'd all still be using (a much more powerful) DOS, and Jobs' and Gates' bank accounts would be counted in the mere millions instead of the billions.

1988

1988 was Ronald Reagan's last year as president, and the year George Bush (the father, not the son) got elected. FM radio broadcast Michael Jackson, Phil Collins, INXS and Guns N' Roses, and record stores sold them on vinyl. Newer computers sported a 386 processor with 640KB (yes, KILObytes). Wordperfect was the wordprocessor of choice, and Lotus 123 ruled the spreadsheet market. Printers were dot matrix, except for the new $2K Laserjet II laser printers. It was long ago, and lightyears from today's computers.

And yet, people used computers. Not Geeks, ordinary people. Clerks, secretaries, business owners, and the more adventurous doctors and lawyers, worked on command line DOS, and did excellent work. Wordprocessing, spreadsheeting, drawing, accounting, and even bulletin boards and email. A little training or experimentation, and they mastered the computers that Gates and Jobs later declared unlearnable. I was there: I saw legal secretaries make those ancient computers walk and talk. I saw legal secretaries hacking those computers. Anybody with an average IQ, ability to listen and read, and a modicum of curiosity could turn 1988 computers into productivity fountains.

Note:

If you wonder why Gates and Jobs conducted a huge campaign to convince people that the then-current technology was unlearnable by mere mortals, just follow the money.

Perhaps you like the speed, simplicity, and efficient screen usage of dwm. Perhaps you like the way a configuration with Linux, dwm, xxxterm, and dmenu, can run snappily on the fleet of WinXP hardware you would have had to replace if you'd wanted to run a later Windows version. Then read on, and I'll tell you how your employees can use such systems right along with you...

Do the preceding, and your employees won't need a start button or a window list. And remember, if 1988 legal secretaries could work at the DOS command line, your employees can certainly work in dwm, with instructions available at any time by pressing Ctrl+Shift+F1.

The following diagram shows the call structure of the most universally applicable dwm installation sporting its own wallpaper:

Keep referring to the preceding diagram, to clarify things in your mind, for the rest of this article. Here's the narrative version:

The dwm called by lightdm or startx or xinit or whatever symlinks to a script that disables the old wallpaper, displays the new wallpaper, and then executes your customized dwm. The line that displays new wallpaper is actually an sh call to a one line script that is not permissioned executable.

Make HTML file listing hotkeys for xxxterm, dwm, and dmenu.

Keep it simple. Hotkeys and functionalities, in a table, grouped by functionality type. Obviously, document the hotkeys as you've customized them, not as the came originally "from the factory". Start with all the xxxterm hotkeys, because the user is reading the instructions in xxxterm. He or she need to know that j scrolls xxxterm down and k scrolls up, Alt+f brings up bookmarks.

Then list all the dwm hotkeys, starting with the dmenu function. If your employees should work with only a limited list of applications, you can pipe that list into dmenu so only those apps show up on their menu.

Then list all the workspace commands (call them "workspaces", even though we know they're tagsets). All the window handling commands. All the layout commands.

You should probably include some links to deeper information, so, for instance, they can get themselves out of trouble if they accidentally get into float layout, or press Alt+d or Alt+i and have a layout that doesn't match what they're used to.

Note:

It might be best to disable Alt+d and Alt+i so your employees can't get into those situations in the first place.

Go only so deep with your documentation as you want them to take it before calling tech support.

Create wallpaper with "Press Ctrl+Shift+F1 for Instructions"

Use Inkscape to create it in SVG format, then export to .png. Mine looks like this.

Install that wallpaper

What's going on here is you want the dwm executable, perhaps package installed, to be backed up and then changed to point (via symlink) to a short script that installs your chosen wallpaper image before running the dwm you configured and compiled.

Modify dwm so Ctrl+Shift+F1 runs the HTML file in xxxterm

Note:

Obviously, you'll need to code shellscript dwmhelp.sh so that it runs xxxterm on your HTML help file.

Put the preceding line right with all the similar commands, such as *dmenucmd[]. And further modify config.h to include a hotkey something like this:

Put the preceding with the other hotkeys: they all have a similar structure and are easy to find. If you haven't yet defined SHIFTCTRL, it looks like this:

Install the Symlink

Before going into this again, here's another diagramatic look at the call architecture:

Start by taking the executable you just made and rename it to dwm_customized. Now there's no confusing various dwm versions.

Next move your existing (perhaps package installed) dwm to something like dwm_ubuntu in the same directory as before you moved it. Now, if you ever want to run the original dwm, you can just do a backup and rename.

Then symlink to dwm_customized from dwm. This way, if lightdm is governing your choice of wm/de's, dwm is still on the list, but it runs your dwm.

I Confess: I'm In Love With Dwm

In case you haven't guessed by now, while writing and tech editing this Linux Professional Magazine issue, I fell in love with dwm. To the point where I don't feel like writing much about Openbox, JWM, IceWM, or other excellent wm/de's. I've spent over a week researching dwm, and loved every minute of it, but now I need to briefly describe the other wm/de's, and then publish this magazine.

Openbox

If it weren't for dwm, this article would enthuse that Openbox is the best wm/de ever made. According to netblue30's chart, although 7 times more memory consuming than dwm, Openbox is still a svelte 7MB. Compare that to 36MB for LXDE and 70MB for Xfce, and it's obvious Openbox is still small and quick. And with its excellent implementation of root menu, its best of breed window list sorted by workspace (called "client-list-combined-menu" in the config file), its magnificent workspace navigation, and its faultless implementation of Alt+Tab, Openbox is a productivity factory. For the touch typist who knows the hotkeys, Openbox is just short of light speed.

Warning!

Always back up ~/.config/openbox/rc.xml before editing it!

Configuration in Openbox is a pleasure. Just edit ~/.config/openbox/rc.xml. Remember, when configuring hotkeys via ~/.config/openbox/rc.xml, you need to use the key name delivered by the xev program. Just run xev from a maximized terminal, press the key (without the modifier), and see what xev calls it. Here are some examples:

As you can see, there's no rhyme or reason to the key naming, especially the use of upper and lower case, so just use the names reported by xev.

Key desc	Xev reported key
`	grave
Enter key	Return
Backspace key	BackSpace
Delete key	Delete
Delete key on keypad	KP_Delete
;	semicolon

For some types of configuration (but not hotkeys), you can use the obconf executable for configuration. It's handier, and of course there's less chance of you making an Openbox busting mistake.

Use an Openbox Margin

Except for tiling, Openbox has all the keyboard capabilities of dwm. When it comes to the mouse, however, Openbox is handier. Keep in mind most mouse functionality comes from clicking on the desktop itself, which is often covered by windows.

No problem. Open obconf, click the Margins tab, and set the left margin at 6px. After doing that and reloading Openbox, you'll have a 6 pixel line up the left on which no window will fall. You can always access the bare desktop in those six pixels on the left. You can click there to control Openbox with your mouse.

Reloading Openbox

Openbox's greatest advantage over dwm is speed of implementing a config change. First of all, like most wm/de's, and unlike dwm, you needn't compile. But much more importantly, the root menu has an item called "Reload", that reloads the configuration without killing the running GUI apps.

JWM

Weighing in at just 3MB on netblue30's chart, JWM is quick and handy. It's the lightest wm/de I've found that has a panel (taskbar), so if you want light but you need a taskbar, this is the way to go.

JWM is no raving beauty. It would be right home at that place, in the seedy part of town, that sells military surplus clothing and equipment. If it were a car, it would be a 1965 Ford pickup with 200K miles. But it's snappy and productive.

Note:

To put your changes to ~/.jwmrc into effect, you must restart JWM. One beautiful thing about JWM is you can restart it without causing your current GUI apps to close or crash, although personally, I'd make sure all my GUI app data was saved before restarting JWM.

Within ~/.jwmrc, each hotkey is defined by a mask, a character, and a functionality. The mask contains zero or more of the following characters:

Char representation	What it means
C	Control
A	Alt
S	Shift

As mentioned before, the hotkey consists of a mask, a character, and a functionality. The character can be almost any character on the keyboard. For some characters, especially the alphabet and the digits, the character can be represented by the character itself (lower case). In other cases, such as punctuation, the function keys, and navigation keys (arrows, home, end, etc), you need to use either the key name or key number delivered by the xev command.

As far as the functionality, here are two examples: One of an internal window manager command, and one an external command to call an external program:

Declaration	Functionality	Type
close	Close window	Window manager command
exec: xterm -e htop	Run htop in an xterm	External command

You can also change colors in ~/.jwmrc. I changed the titlebar and border color of the active window to bright red so its instantly recognizeable. I also changed the background color of the active TaskList button to yellow, once again so it's recognizeable at a glance. The TaskList coloring will be discussed later in this article.

If your JWM installation doesn't have ~/.jwmrc, no problem, just perform the following command:

Warning:

If you already have a ~/.dwmrc, the preceding command overwrites it, so be careful.

Once you've performed the preceding command, you have your own ~/.jwmrc, so you can modify your system to your heart's content.

Why JWM is Cool

Did I mention JWM is fast? Ultra-cool is the fact that the menu system responds to Vim keys intuitively. j goes down the menu, k goes up, l plunges one level lower (to the left), and k ascends out of a lower level to a higher one. If you use Vim, your fingers will understand the menus long before your brain does.

Of course, I would have liked it even better if JWM did menus the Openbox way, you type the letter and it goes to what starts with that letter, type it again, you go to the next item starting with that letter. But you know what? Vim keystrokes on the menu is something to which I could get very accustomed. And of course, at least JWM has a root menu, unlike dwm.

I like the way everything's configurable in JWM, and the config doesn't depend on some lame Qt or GTk library. And I like the fact that a wm/de this light has a panel. It's a decent panel too. It comes with a CPU graph and a clock, and when I run Clementine and Skype, they both get their own completely functional tray icon on the JWM panel. Those tray icons are very small, but hey, did I mention that JWM rates a 3MB on netblue30's list.

JWM's workspace handling is just like that of Xfce and Openbox, which is to say outstanding! Another thing I like is I don't need to worry about themes, I just set the appearance the way I want it within ~/.jwmrc.

JWM's Achilles Heel

Yes, a person not too concerned with aesthetics might conclude that JWM is the perfect work environment. Until he or she tries to switch between a bunch of windows. My copy of JWM came configured with Alt+Tab mapped to JWM's next function, which is not at all what most of us are used to. We're used to an Alt+Tab functionality that toggles between two windows when you perform one Alt+Tab each time and then stop. This is what JWM's nextstacked functionality does. The next function simply goes to the next one on the list, regardless of which window had focus before this one.

It might seem a good idea to change Alt+Tab to nextstacked, but it only seems that way. That's because JWM window switching has a much deeper problem: During repeated consecutive Alt+Tabs, when you don't release the Alt key, there's no visual cue, in the window area, as to who has focus. The best you can hope for is to watch the window list on the panel. And with the nextstacked functionality, the highlight skips around seemingly randomly (actual in reverse order of how you go to this point). It's confusing.

The best workaround I've found for the lack of feedback in the window area is to keep Alt+Tab at next, and hotkey Alt+grave (the grave accent/tilde key right above tab) to functionality prev. This way the highlight on the panel/taskbar, the only feedback you have, goes one direction or the other, without skipping around and confusing you. It's too bad that this workaround leaves no functionality to alternate between two windows on a workspace loaded with windows. One possibility would be to hotkey yet one more all-left-hand Alt command, perhaps Alt+z, to nextstacked.

Looking at the way JWM and dwm do window switching, and I have to grudgingly admire Bill Gates for the way he made his Alt+Tab key work in win9.x through Win7. Intuitive, visually keeping you in the loop, it was perfect. Xfce and Openbox copied Gates' interface, others couldn't.

Speaking of visual feedback, given that the only window-switching feedback is on your taskbar window buttons, you'd better make the button of the focused window obvious. The way my JWM came from Ubuntu, the focused button was a slightly different shade of gray than the others. I made it #ffff00. Now it's obvious at a glance.

Bottom Line

The bottom line is that JWM is a great wm/de. Almost all activity is fast, both from a keyboard standpoint and from a processing standpoint. Its Vim style menu keyboard interface is a breath of fresh air. It's extremely configurable, and you don't even have to compile it to do so, which means the same JWM executable can be used by different users wanting different interfaces. It has a taskbar with time and CPU graph, and the taskbar has a tray to accommodate tray type applications, including nm-applet. JWM's workspace handling is outstanding.

JWM's one drawback is its window switching. A combination of changing hotkeys, brightly coloring the window button of the focused app, and getting used to it, will probably render its window switching a very minor inconvenience.

IceWM

I have a love-hate relationship with IceWM, whose rating on netblue30's chart is a slim 4.5MB, coming in a little lighter than Openbox and a little heavier than JWM. If you want a seriously lightweight interface that can be made to have the look and feel of more professional interfaces like Xfce, WinXP or KDE, you might just like IceWM. If you're willing to do the work.

IceWM, straight from the factory, as delivered by Ubuntu 13.10, is utter nonsense. When navigating the start menu, you need to click at every single level just to see the next level. I expect this nonsense from Windowmaker, but not from IceWM. You need to configure it away.

And configuring IceWM isn't easy. You need to know the config files, know where to find them, and make copies in your ~/.icewm directory, then edit them. They're long, they're complex, and because they're not XML, Joe Average can't just whip up an application to modify them.

Oh, there are such applications, but I couldn't find them in the Ubuntu packaging system. So you need to search for the config files, and some of them occur in multiple places just to fake you out. So, look for the config files with these commands, after running updatedb as root:

The directory at the intersection of all three of those commands is the most likely place to find the raw, example config files.

Hint:

I didn't find them in the /etc tree. The ones in the /etc tree were, for my purposes, decoys. I found the useful ones with all possible config options in the /usr/share/icewm/ directory.

For each of those config files that you need, copy it to ~/.icewm, and edit that per-user copy. The first thing you need to do, so that you can have any chance at all of productivity, is fix the menus so a hover produces the submenu. Edit ~/.icewm/preferences, search for string "MenuMouseTracking", and set that item equal to 1, so the finished product looks like the following:

About Those IceWM Config Programs

Everywhere you look, IceWM fans point you to all sorts of configuration programs to make it easier to change your config files. Good luck with that. At least with Ubuntu 13.10, you can't get them from the package manager, you need to go grab them off various one-man-band websites. The websites are easy to find, but these config programs seem to be maintained and distributed by one programmer who's gotten annoyed and exhausted by user demands, and gone on to other things. More often than not, your web search ends with a notice about how the tool isn't available, and if you find it it's unsupported. Ummm, no. I'll edit the config files.

But even that isn't easy. The config files are long, and you don't know what you're looking for. And don't even think of editing your IceWM menus: Been there, done that, the highway to heartache.

Why the Hostility, Steve?

What, do I sound mad? Maybe it's because the maintainer of one of those config programs snotted me off after I emailed him that icepref had been great, and why did he change it to icepref2, which required the latest this library and the latest that library and was uncompileable on my (then) Mandriva system. But that's petty, it goes even farther than that. See, IceWM and I have history.

In 2001, my 64MB RAM Celeron with Mandrake wouldn't run. It swapped, and finally crashed. It was useless. In desperation, I searched for and found a Win9x-interface, lightweight wm/de, called IceWM, to replace my beloved KDE.

I installed and used IceWM, and all of a sudden it ran fairly well. Not wonderfully, 64MB is paltry in any language, and my mobo was still an intermittent piece of junk, but it ran, and I was able to do work on it.

I was so impressed that I replaced KDE with IceWM on my high end 512MB RAM dual Celeron 300A cranked up to 450Mhz, and that machine ran an 9.9 second hundred meter dash. I never used KDE as a wm/de again, although I used Kmail and K3b for years after.

Learning everything there was to know about IceWM, I made my computer (and the ones that followed) into finely tuned productivity tools. Somewhere around the mid 2000's (like somewhere around 2005) the developer snotted me off about Icepref, and although I didn't switch out, I wondered whether software with this kind of authorship should be so integral to my business.

After switching from Mandrake/Mandriva to Ubuntu in early 2009, just for fun I used the Gnome2 interface that shipped standard. And you know what? It was just fine. I liked it. And I knew more than one person was writing it. Here are the two things I remember from my IceWM days:

IceWM Themes

IceWM has many excellent themes available through the Ubuntu, and I presume other, package managers. Also, several people on the web have made very nice themes installable without much work. It's a very good looking wm/de.

Add the Usual Suspects

IceWM is so good looking it would be easy to forget that it's light, and it doesn't come with its own tools. Fine. Hotkey to dmenu_run: Heck, IceWM's root menu isn't all that productive anyway. Use xxxterm instead of bloat brothers Firefox and Chrome/Chromium. Find some good terminals to use. You could do a lot worse than to run IceWM and use Xfce and/or LXDE tools for several tasks.

The Bottom Line

If you're willing to commit to the work of configuring IceWM, and you understand that it's not developed by a big crew, and it's written in C++ so the likelihood of your maintaining it yourself (a la dwm) is low, then IceWM can serve your needs admirably. It's like an ultra-lightweight LXDE, without the slow mouse problem.

July 2, 2014, about a month after I finished most of this LPM issue, GoLUG (Greater Orlando Linux User Group) hosted a Window Manager Desktop Environment shootout, and one of the guys demoed the i3 WM/DE. And man, it was great. It's a keyboard-centric tiling window manager like dwm, but with much more choices in carving up your screen. You can turn three or four apps into one tabbed app. To truly appreciate i3, you'd need to see a skilled practitioner put i3 through its paces.

I'm going to research i3 more, and if it's as good as I think it is, I'll be switching to i3 in the not too distant future.

I Feel the Need -- For Speed

You know, if all I did all day was email, web browsing and a couple of games, you know what I mean, fun instead of profit, any old wm/de would be OK. KDE, Gnome, Unity, Windows, it would all be the same to me. When you do two or three things all day, your concentration is 100% on your apps, and 0% on what runs them. Heck, you open your mail client, web browser, and games in the morning, and maybe, to save electricity, you shut down and power down your computer at night.

Matter of fact, if what you do is web, mail, and games, and none of it professional, why not just do it on your cellphone? You can carry your "computer" everywhere you go

The guy described in the previous two paragraphs doesn't need to write 2000 words of content per day. He doesn't need to create or incorporate images on a deadline. He isn't responsible for writing several functions worth of code debugged and tested code per day. His "computer" means totally different things to him than it does to people like you and me.

I feel the need for speed. This Linux Productivity Magazine issue isn't finished, but it's already 17,160 words of ideas, research, and ideas replaced by better ideas. Shellscripts, and installations. All while handling client emails, and keeping current money coming in. And interspersed with participating in my online communities. Tasks switched out of, tasks returned to and remembered. You just don't do that on Unity or Windows 8.

Staying On Track

A half second latency, or a half second move between keyboard and mouse, can cost you much more than a half second. If you're doing real work, you're juggling many ideas in your head, and those thoughts are at the edge of your capabilities. When that half second delay causes your thought track to switch from your idea to the manual operation of your computer, you can lose ten minutes trying to restore your mental state. Let that happen a few times per day, and it's a productivity drain.

A fast interface does more than save seconds: It saves thought trains, and those thought trains are what most of us get paid for.

The Naysayers

When you move to a swift, responsive, and most likely keyboard-centric user interface, many's the voice who will call you impractical. Say you've lost touch. Say you're a Geek and they're not, as if only Geeks can perform tasks that aren't obvious to an eight year old.

Then you look at the work they do, and you understand. They code Rails of Django all day, using an editor and a web browser as a manual and a test environment. Two apps. Maybe once in a while they call up a presentation program like MS Powerpoint or LibreOffice Impress, to make a presentation for their local Python group. They can have the same five applications open all day and get all their work done. They use Macs, and they're the most sophisticated critics you have. It goes down from there.

Some are salesmen and lawyers. Their most voluminous writing task is an occasional 200 word, top-posted email reply on their smartphone. They have "people" to do computer tasks requiring actual production on a computer.

The gamers mostly run Windows because that's where the games are, at least until Windows gets Steamrolled, and oh by the way, did you notice that this is called "Linux Productivity Magazine?

At work people use what their employers tell them to use, and given their employers' employee retention problems, their employers prioritize an easy first day over everything else. I mean really, how much training do you see employers doing? They figure the employee will be gone in three months, and a lot of employers make that a self-fulfilling prophecy.

But you and I, we're different. We need a real keyboard, and a real mouse, and if they ever invent a useful foot pedal, we'll need that too. We need a big screen showing multiple apps. Because our computer isn't mainly a communication device, or a fun device, or even a research tool. To keep our jobs, or perhaps just to keep doing what we do best, our computers must be production factories. You and I: We feel the need -- for speed.

Steve Litt is a fan of fast interfaces. Steve can be reached at his email address.

Decisions, Decisions

All email clients suck. All cell phone companies suck. All broadband Internet Service Providers suck. So why are there so many outstanding wm/de's? Xfce, LXDE, Openbox, IceWM, JWM, dwm, they're all productivity fountains. And there are probably ten or twenty more outstanding wm/de's that I never had time to try out. How can so many of a category be so good?

And more to the point, how the heck are you going to choose? My answer is, "it's a process."

Step one of the process is certainly to install Suckless Tools so you can use dmenu. Hotkey it from your current wm/de, and get used to the hyper-productivity it brings. Installing, hotkeying, and using dmenu has no cost, bestows tremendous productivity gains, and also gets you into the keyboard-centric frame of mind.

The next step is to install and use xxxterm (remember, your Linux distribution might call it Xombrero). This step has some cost: Until you get used to xxxterm's hotkeys, your productivity will be less than your productivity using Firefox, although you'll spend less time killing Firefox and its spawned plugin-container instances. Take it from me though, keep an xxxterm cheat sheet (like the one in this Linux Productivity Magazine issue), and two weeks from now you can get rid of the cheat sheet, and you'll be very glad you switched.

xxxterm will be slower at first because you don't know the hotkeys, so at first use it in parallel to Firefox or Chromium or whatever you're used to: Use xxxterm for things you can take some time on. After a week or two you'll start to notice you work faster on xxxterm.

The next step is to try a no-panel environment for awhile. I'd recommend you install Openbox, and change its keystrokes to suit your particular needs. Remember to use an easy hotkey for dmenu_run, and remember that, if once in awhile you need a panel, you can run lxpanel.

Note:

Try to run without a panel most of the time. The purpose of this exercise is to see whether, after practice, you prefer a panel or no-panel environment, and you can't judge that if you're running a panel all the time.

After a couple weeks without a panel (most of the time), decide whether you liked working without the panel better than with one. Then you can decide whether you want a panel on a regular basis or not.

Preference	Matching wm/de's
Panel	Xfce, LXDE, IceWM, JWM, and many more
No panel	Openbox, dwm, WindowMaker, the "boxes", and many more

If you decide to go no-panel, you need to decide which one. In deciding between Openbox, along with the zillions of other no-panel environments, as opposed to dwm, ask yourself whether you'd enjoy, or at least tolerate, modifying a clearly understandable config.h file, and recompiling. If the answer is "no", that rules out dwm, but before you say "no", why don't you try it once. Recompiling dwm is a heck of a lot easier than configuring IceWM, WindowMaker, and probably most of the *box wm/de's, and not much harder than configuring Openbox.

By the time you've done the preceding research, you'll probably have a good idea what you want for a wm/de, and are ready to decide exactly how you want to set up your swift, responsive computer.

Hotkey	fcn	comment
Alt+Space	Toggle tiled/monacle
Alt+T	Tiled layout
Alt+M	Monocle layout
Alt+f	Floating layout	Float is quirky, key conflicts with apps' file submenu, try not to use
Shift+Alt+Space	Toggle float on and off	Use to fix weird layout modes
Alt+<digit>	View <digit> tagset
Shift+Alt+<digit>	Assign tag <digit> to window
Alt+0	View all tagsets
Alt+p	run dmenu
Alt+j	Cycle thru windows
Alt+k	Cycle backwards thru windows
Shift+Alt+c	Close focused window
Shift+Alt+q	Quit dwm	Log out