All the Linux desktop action these days is in KDE and GNOME, but on older hardware, servers, or anything else where you need to squeeze every last ounce of performance from the box, something lighter is needed.

My Linux box at work — a 300 MHz Pentium II — runs WindowMaker. It’s familiar, it stays out of the way, and it doesn’t tie up the memory or CPU that a modern version of KDE or Gnome (or Windows, for that matter) would. But you need to add applets like a clock or a desktop pager. You can find them easily enough — I ended up using the aptly-named wmclock and wmpager – but there’s a significant problem with both. WindowMaker lets you change the size of the dock icons, but when I shrank the dock to get more space I discovered that both applets have a hard-coded size of 64×64 pixels.

As you can see, a 64×64 applet just doesn’t work in a 48×48 space. It surprised me, though, since these dockapps are designed specifically for WindowMaker, and it’s WindowMaker itself that lets you change the size. You open up Preferences, change the size, and restart WM. Just menus and buttons. No config files, no registry, no third-party add-on. This isn’t an esoteric hack that takes serious effort to find, it’s a basic feature. You might as well design a Mac program that assumes the Dock is on the bottom of the screen. For most people it will be, but it’s not rocket science to move it.

In my ICS classes, they always discouraged us from using “magic numbers” — just throwing a number in the code without identifying or abstracting it. There are two very good reasons for this. The first is that you might forget what this 64 is doing. The second is that you might decide to change it later on, and it’s much easier to change one SIZE=64 definition than to track down every 64 and hope you’ve neither missed any you need to change nor changed any you need to leave alone.

Those dock applets are stuck at 64×64 pixels because the programmers were thinking in terms of the pixel grid, not in terms of actual display size. They weren’t designed to appear 1″ x 1″ but were designed pixel by pixel, assuming no one would change the default size. But that size is configurable, and 64 pixels wasn’t selected for any intrinsic value, but because it worked well on displays of the time.

Screens are getting bigger, and every year video cards can display higher and higher resolutions. The classic 32×32 icon is starting to look small, and the last few years have seen a trend toward scalability in desktop design. Windows icons are designed at several sizes. Mac icons are designed large and scaled down as needed. KDE is moving to vector-based graphics. These are different approaches, but they deal with the same problem: accommodating both the casual user with the 800×600 screen and the power gamer with the 2048×1536 mega-display.

It’s not just icons and GUIs. For several years it’s bugged me that web images are not just pixel-based, but pixel-sized. You can scale fonts and CSS elements by actual display size (to a point), but images are still tied to the density of the screen. All you have to do is print a web page and you can see the difference in resolution. Wait a few years, and that 400×300 photo is going to look like a thumbnail. Graphical menus won’t be readable anymore. Those antipixel buttons you see to the right, with one pixel-thick letters? They’ll be completely illegible (though CSS buttons ought to do okay). And while active websites will adapt with each redesign, what of the millions of live, but unmaintained sites? You know, the sites that still have useful information, but haven’t been updated since 1997?

All those width and height attributes, all those gifs, pngs and jpegs, they’re all done with magic numbers. And they’ll all need to change to something real eventually.