Features

MIWM features

miwm has the following features:

miwm uses the GPL from Free Software Foundation, as discussed here. It is thus an Open Source project, as defined here. The main Sourceforge page of miwm is here, and the latest releases can be downloaded from the Downloads section. The online CVS tree can be browsed here. It is usually easiest to analyze a window manager by starting with how it handles x events and either does something or passes it to a client window. It is recommended that you start analyzing miwm with the file disp.cc If you fix bugs or make improvements, please send e-mail to the developers, or become one yourself, so that the changes may be merged back into the main line. Developers are listed on the main miwm project page.
Extremely simple and Zen appearance and function. No icons, only one simple menu. It is built on command line functionality, largely because of dislike for the choice between
- constantly navigating through a comphrehensive but deep tree sub menus in order to get to the particular set of utilities/folders you are using a lot this week, or
- constantly reconfiguring my windows so as to make this week's set of utilities/folders be easily accessible, or
- always using the same small set of utilities/folders, which are near the top of a small static menu configuration.
Basically, command lines offer far more options, with far fewer finger-motions than deeply nested menus

The command-launcher menu can be reconfigured via the miwm.usermenu file, in ~/.miwm directory. An example is included in the distribution, called miwm.usermenu, so you will have to move and rename it. We find that Luiz Henrique de Figueiredo's button shell tool bs is excellent for implementing sub-menus from this main menu, and that is illustrated in both the same menu file and the screenshots below. It's a pretty useful tool regardless of your window manager.

The appearance and behavior options can be reconfigured via the miwm.config file, in ~/.miwm directory. An example is included in the distribution, called miwm.config, so you will have to move and rename it. Defaults are set at compile time, via the miconfig.h file, in case this file is not present.
Virtual desktops. You decide at compile time how many desks you want and what their names will be. It comes with a standard setup of six, called "one" to "six". You can change the number and names in the miconfig.h file. As with most of the configuration, miwm uses an existing language (C++) to describe the configurability desired, rather than make up a new one (Have you ever studied the syntax of an .fvwmrc file? Written a lex/yacc pair for it?)
Optional tiling of windows. Windows can be neatly tiled whenever they are created. You can always retile all existing windows, which can be very useful in cleaning up. Constant auto-retiling and resizing can distracting, so it eliminated it in favor of the only-on-command approach (change it with the root menu).
Efficient. Small footprint in system resources, fast.
- The executable is small
- No memory leaks at all, as far as my tools can detect.
- Does not have lots of fancy fonts, images, etc.
- It does not waste precious laptop screen space on icons, task bars, desktop short cuts, etc.
Reliable. I've run it for weeks at a time, on Linux, Irix, and Solaris, Cygwin, BSD, on single workstations and across a busy network, and it has not crashed, lost a window, grown to enormous process size, become 'unstable', carried around ghost windows, or exhibited any other insidious maladies. The most testing and experience has been on Red Hat Linux 7 to 9 and Debian (woody). As you can see below, it had been up and running nonstop for 28 days at the time of the obligatory screen shots.

If you don't like minimalist aesthetics, miwm is probably not the tool for you. Many other choices are available through this website.

Memory Leak Detection

miwm includes a very simple, general purpose memory leak checker and debugger. It is contained in the two files mlchckr.h and mlchckr.cc.

Basically, mlchckr overloads new and delete. It maintains a vector of memory blocks. Each new allocation adds a block, and each deallocation removes it. It detects double-deletes.

It has four meaningful levels of debugging:

Level 0: no checking or tracking is done. It's just a pass-through to malloc and free
Level 1: tracks only the number of blocks left allocated at program end.
Level 2: same as level 1, plus at the end, it prints out a list of their sizes and ID numbers
Level 3: same as level 2, plus prints a running log of each allocation and deallocation. This can get quite voluminous

The API is simple:

void StartMemoryLeakCheck(unsigned int): Start memory leak checking, at the specified level
unsigned int FirstSuspectBlock: If this is greater than zero, the allocator will invoke the xxgdbDummyFN, so that you can put a break point there (with xxgdb, kdbg, or such). Set this right before starting to check leaks.
void xxgdbDummyFN(unsigned int bid): this is just a place in the mlchkr.cc file where breakpoints could be set
void StopMemoryLeakCheck(unsigned int): Stop memory leak checking, and print data (if appropriate)

The purpose of FirstSuspectBlock is to enable you to set a breakpoint that will stop exactly where the leak originated, without too much tedium. First you run your program with Level 2 checking, and pick a leak to fix. But when you have a memory leak on the 42,719-th block allocated, it is really tedious to step through 42,718 allocations to get to where the bad one happened. The solution is to set the first suspect block to 42719, set the breakpoint, and on the next run it will hit the breakpoint only when the bad allocation happens. Usually, for well-structured code, seeing where it was allocated is enough to make it obvious how to fix the leak.

Clearly, the above process depends on repeatability. To help that, a simple random number generator is included in miwm. It is completely contained in rng.h and rng.cc. It produces reasonable sequences, with complete repeatability. If you want true randomness, use /dev/random ! Better PRNG's exist, but this is a good compromise of randomness, simplicity, and repeatability.

The primary problem with mlchckr is that it stores the memory blocks in a vector. This means N^^2 time to handle N items, which can get to be a noticable penalty for programs that hold lots of data in memory at once, like A* search. A newer version, called ml, uses a splay tree for N lg(N) performance, and negligable performance penalty.