Drawers for WindowMaker

Wmaker in action! The aspect of my desktop is unusually wide because I use two physical monitors side by side. Windows may be dragged accross the screens, you just need a background picture that is up to the task!

WindowMaker (or wmaker for short) is an excellent window manager.

For the uninitiated, a window manager is simply the program that… manages how windows are displayed (seriously!), that let the user move them, resize them, possibly organise them in so-called "workspaces", etc.

Wmaker is free software, free as in "gratis" and, most importantly, as in "Freedom". That means that I have the right (just as anybody) to actually see how it is written, to modify it and to share my modifications with the rest of the world. My main contribution is a patch that adds to wmaker "drawers" that store "AppIcons". While I was at it, I found and corrected a couple of minor bugs.

The icons lead to patches that apply to the last stable version of wmaker (0.92.0 today). These patches generally apply to the version distributed by Debian etch (version 0.92.0-6.1 today) as well. If not, a patch specific to Debian is available through a second icon .

Name	Link(s)	Short description
Spurious EnterNotify		Minor bug fix (details).
Useless tests		Small code cleanup (trivial).
Useless test		Tiny code cleanup (explanation).
Omnipresent AppIcon StartUp		Minor bug fix (details).
Avoid Dock Flickering		Minor defect fix (details).
Clip Auto Delays		Make customisable the times after which the clip expands, collapses, raises and lower automatically (description).
Smart Placement		Minor bug fix (details).
Switchp auto focus		Fix a misbehaviour with the switch panel when focus mode is set to "auto" (details).
Window menu		Increase the maximum width of the window menu (trivial).
Drawers		Now the big part: add drawers to wmaker. Drawers belong to the dock and may contain AppIcons, horizontally (details).

Some patches in this table actually require the application of the patches "above them". Therefore, are also available for your patching pleasure all of the above patches in one, and all the Debian patches stored in one archive.

How to use those patches

The prerequisite is the ability to compile and install wmaker from its sources. To use the "classic' patches ( links), apply them as follows:

tar jxf WindowMaker-0.92.0.tar.bz2
patch -p0 < the_patch
cd WindowMaker-0.92.0
./configure [your usual options] && make && make install

As for Debian patches ( links), drop them in debian/patches:

apt-get source wmaker
cp the_patch wmaker-0.92.0/debian/patches
dpkg-buildpackage [your usual options]

Naturally confident and lazy? Here you go, if you trust me enough to install this binary package Wmaker 0.92.0-6.1 + drawers.

Contact-me if you run into some unexpected problem, or if everything goes well and you like it! ;-)

Known problems

I only know of a few minor problems:

A seemingly weird behaviour when the Dock is not "Kept on top" and the drawers are set to "Auto-raise".
Right after creation (and only then), drawers act as if they were "Kept on top", even if they are not.
There is already a program named WMDrawer, it is a bit of a worry that I use it internally.
To day, nothing more serious (no crash, not to mention no data loss).

Below is a detailled description of some of the patches.

Moving wmusic inside my "audio" drawer.

Drawers

Description: one life-time achievement ;-). The dock (at the left- or right-hand side of the desktop) may now hold drawers. These drawers may in turn hold --horizontally-- AppIcons, either dockapps or AppIcons from regular applications. Just as the clip, the drawers may auto-expand, auto-raise, or both. Adding AppIcons to drawers, as well as selecting the drawer's icon or place in the dock, is entirely controlable with the mouse.

Back to the patch table.

SwitchPannel Auto Focus

Bug overview: The switch pannel interacts poorly with the "auto" focus mode and may end up giving the focus to the wrong window.

The switch pannel in action (for decorative purposes ;-).

How to reproduce it:

Setup two windows in a workspace, one at the center and the other at a corner. Move the mouse to the center of the screen, so that the focus goes to the center window. Now, with the help of the keyboard (with Alt-tab, typically), try and switch the focus to the other window. In doing so, the switch panel shows up, gives the focus to the other window and then disappears. However, its disappearance make it seem to wmaker that the mouse has just entered the center window, so wmaker gives the focus to that window again.
It is a lit bit more involved. "Raise window when switching focus with keyboard" needs to be set. In a given workspace, maximize a first window A, then setup "above" window A two windows B and C (one in the upper left corner and the other one in the lower right corner, for example). Move the mouse so as to give the focus to window B. Press the Alt key, hit the key tab once (window A moves up to the "top"), then another time (window C is then selected). Eventually relase the Alt key: window B is given the focus again.

Correction: it is a matter of ignoring some (EnterNotify) events when the switch panel is active or has just been used.

Back to the patch table.

Spurious EnterNotify

Bug overview: if an AppIcon is moved rapidly over a Clip set to auto-expand, the latter may erroneously auto-expand afterwards.

How to reproduce it: set a Clip to auto-collapse, and make sure it contains a (random) AppIcon, so as to easily visualise its open/close state. Now move rapidly an AppIcon over the Clip. Try to move it so fast that the cursor sometimes is out of the AppIcon's tile. Then, replace the AppIcon out of the Clip.

Explanation and correction: if, while the AppIcon was being moved, the mouse cursor entered at least once in the Clip's tile, the latter is going to receive an EnterNotify event (after the AppIcon is replaced) and thus expand automatically after the relevant delay. The solution is to simply "gobble" (i.e., ignore) all EnterNotify events when moving an AppIcon.

Back to the patch table.

Useless test

Explanation: if btn is omnipresent, it has been moved to the current Clip by wWorkspaceForceChange() -> wClipUpdateForWorkspaceChange() -> moveIconBetweenDocks(). Thus, btn->dock is always the Clip in which we entered.

Back to the patch table.

Omnipresent AppIcon StartUp

Bug overview: right after start up, omnipresent AppIcons (living in the Clip) are displayed but non-functionnal.

How to reproduce it: place two AppIcons in the Clip, make the first one (A) omnipresent and leave the second one (B) as is. Make the Clip "autocollapse". Move to the second workspace and restart wmaker. Wmaker starts in the first workspace, and the Clip there looks closed (its text color corresponds to the closed state, AppIcon B is not shown), but AppIcon A is displayed. However, A does not react when the Clip expands or collapses. A click on A makes it disappear. Fortunately, changing to another workspace fixes the problem definitively.

Explanation and correction: internally, wmaker maintains as many clips as workspaces. When the user switches to another workspace, the omnipresent AppIcons are moved to the new "current" clip. In the situation above (trying to reproduce the bug), when wmaker restarts, the omnipresent AppIcons are restored in the second workspace, whereas the first workspace is active. A "hack" wrongly forced the omnipresent AppIcons to be displayed. The patch makes sure the omnipresent AppIcons are moved to the first workspace on wmaker startup.

Back to the patch table.

Avoid Dock Flickering

Bug overview: When moving an omnipresent AppIcon in a clip, the latter is flickering.

Explanation and correction: the clip and all its AppIcons were drawn systematically, although it is enough to draw them once, at the beginning of the move of the omnipresent AppIcon.

Back to the patch table.

Clip Auto Delays

Description: The file $GNUSTEP_USER_ROOT/Defaults/WindowMaker may now contain four new variables (the WPrefs.app programs was not modified to handle them yet, so it is necessary to directly edit the file). The four variables in question are ClipAutoexpandDelay, ClipAutoraiseDelay, ClipAutocollapseDelay and ClipAutolowerDelay. They control respectively the time, in milliseconds, after which the clip auto-expands, -raises (after the mouse entered the clip), -collapses and -lowers (after the mouse left the clip). The defaults values (respectively 600ms, 600ms, 1000ms and 1000ms) are weird IMO but correspond to the values previously hard-coded.

Back to the patch table.

Smart Placement

Bug overview: New windows are sometimes mis-placed when the "smart" algorithm is used.

How to reproduce it: be sure (with WPrefs.app, for instance) to use the so-called "smart" window placement algorithm. In an empty workspace, open a first window (for instance, an xterm). The window should appear at the upper left corner. Shade it (hide its contents below its title bar by double-clicking on it) and select another empty workspace. Open another window. Instead of placing it at the exact same place as the first window, wmaker places the new window a little bit lower, or frankly to the right.

Explanation and correction: when placing a new window, wmaker avoided all shaded windows, instead of only avoiding the shaded windows on the active workspace.

Back to the patch table.