darkness

I upgraded my laptop from FC4 to FC5. Actually, rephrased: I desired to upgrade my laptop from FC4 to FC5. I started the upgrade. Package installation begins. Uh oh, CD read error. Anaconda (the FC installer) presents a nice “Would you like to retry or give up?” dialog. I take the CD out, check it, looks fine. I put it back in and click “Retry.” Some amount of churning.

AttributeError: 'NoneType' object has no attribute 'stop'

Uh oh. Looks like that “Retry” won’t be happening. Anaconda has experienced an uncaught exception. Well, OK, lets try an upgrade again. (I should have figured this was a bad idea, CD problems aside. I’ll also note that the CDs tested clean when I ran the CD test after rebooting back into the installer.) CD read error again, same problem with the retry button again.

Third time’s a charm! Made it all the way through upgrade, no bitching. System boots just fine. Well, almost fine: sendmail didn’t start, nor OpenVPN, due to complaints about libcrypto missing. That’s kind of weird, but I figure I just need to upgrade OpenVPN from extras because FC5 includes… a new version of OpenSSL. Sure. (My brain conveniently ignores that sendmail is part of core, and would have been upgraded already.) Start poking around, find some programs missing. Where is gaim? I’m pretty sure that’s in core and I know I had it on here. Huh, I’m missing some stuff in /usr/bin? And some packages are acting weird? Finally I run rpm -qf /usr/bin/* and find that something like half of the files in there aren’t known to RPM.

In retrospect I think what happened was: first upgrade started upgrading my packages. Upgrade failed. RPM database left in an inconsistent state. Future upgrades at that point would probably be futile: RPM has now forgotten everything it knows about half the packages on your system. You need to reinstall. Which is exactly what I did, after a few hours of backing up over the network.

---

FC5 installed fine (no CD read errors, for example). But I was immediately unsatisfied with my window manager, of course. I was not content to put up with kwin’s lack of a “temporarily focus while cycling windows” behavior.

First I thought I’d put it in kwin. Somehow I thought this would turn out better than my Metacity patches, which I’ve long since stopped using since Metacity would crash occasionally, usually preceded by some period of bizarre behavior. Boy, was that foolish of me.

kwin has two modes for cycling: CDE and KDE. CDE does what I want, raising/focusing as you cycle (and no “tab box” or “window list” as they are sometimes called). However, you have no “most recently used” window behavior. For example, say you have windows A, B, and C. Focus window A. Now press Alt-Tab (or whatever your “cycle windows forward” shortcut is) and you’re focused to window B. Let go of Alt. Do some work in window B. Now you want to flip back to window A, as you might be used to (i.e., from MS Windows, I believe). You press Alt-Tab again, but instead of flipping back to A, you’re taken to window C. CDE mode will always go in a circuit around windows, never allowing you to quickly flip back to the most recently used window. That’s a deal breaker for me; otherwise CDE mode would be fine.

In KDE mode you get a “tab box” (“tab” as in “Alt-Tab”) that shows you all your windows. As you hold down Alt and press Tab, you cycle the selection within that tab box. However, as you press Tab, only the tab box changes; the windows being selected in the tab box are not raised nor focused. Once you let go of Alt on a selection, that window is raised and focused. Obviously the problem here is that there’s no focusing of windows as you change the selection in the tab box.

I’ll again state the reason I’m so fond of focusing windows as you cycle through them. On one desktop I’ve typically got 4-8 terminal windows open, and several of them probably have the same (or extremely similar) titles. I know roughly what I expect to see in the window I want (enough so that I probably don’t have to read the contents of the window to know what I want; I recognize syntax highlighting in Vim, or a shell prompt, or a configuration file being paged with less, etc.) and I may know where that window should be on the screen. I quite possibly don’t immediately know its name, though, assuming it’s unique. So if you show me a list of the names of my windows and make me pick one, that requires reading, thought, and sometimes even some guessing (which one of these terminal windows with the same name is the one I want?). If you show me which window I’m selecting, I can quickly determine whether it’s the one I want based on the general appearance of its contents as well as its location on the screen. In summary, it’s must faster and less annoying for me to immediately see what window will receive focus, rather than having to pick the window title from a list.

So kwin was not cutting it. I went and tried some other window managers.

I often come back to look at wmii. I only used it seriously once (back when it was “wmi” if I recall correctly) and then only for a week or two. I put it aside because I had problems with too many weird (and quite probably non-standards-compliant) applications, like XMMS and Firefox. wmii still looks neat. It’s a “tiled” window manager, supposed to be very easy to get around with using only a keyboard. wmii-3 (I gather that’s the name, or future name, of the development release I was using) has an, er, interesting method for customization. wmii has this concept of a “file system” that you get at using a program called wmiir. For example, you do wmiir read / to list the contents of its root directory. You can read the contents of your status bar using something like (off the top of my head, this is probably not 100% correct) wmiir read /bar/0/status. You can change the contents of your status bar with echo "contents" | wmiir write /bar/0/status. In fact, the default configuration forks off a shell script that basically updates the time in the status bar this way every second (ew?).

Now that you know about the file system, know that you can read “events” from wmii by running wmiir read /events (again, off the top of my head). Using this interface, the default wmii configuration implements your keyboard shortcut keys… in a shell script. Yes, your wmiirc is actually an executable that starts in the background and sits in a loop around wmiir read /events | while read event .... At first you may say, “that’s downright insane.” I have difficulty disagreeing. However, it does mostly work: you get an event (a string like Key Alt-Tab), match it in a case statement, then take some actions. Want to move the current window to another desktop (or page, or view, or what the fuck does wmii call them)? Take an action like echo -n 1 | wmiir write /view/cur/cur/tags. Cycle windows? Something like echo -n next | wmiir write /ctl.

I stopped using wmii before I got in too deep. I had some problems with old wmiirc processes hanging around when I’d restart wmiirc. Then I remembered all the old problems I had with wmi, and read the broken applications page which lists some favorites. I also thought about the fact that I go bat shit crazy when my terminals aren’t 80×24. Maybe I also felt like I’d eventually become too obsessed with configuring wmii (I was already thinking about replacing all the shell scripts with Python).

One final thing about wmii; in fact, this is an illustration of how configuring wmii can consume you: wmiish is a quick shell script I whipped up to imitate a shell for poking around in the wmii “file system.” I found it useful for exploring and testing. It’s also… ugly.

---

Moving on, I went for FVWM. FVWM is very configurable, but it still mostly behaves like a normal window manager (that is, it’s not “tiled”). There are (surprisingly?) some attractive window decoration sets for FVWM, such as those found in FVWM-Crystal. In fact, I used the Clearlooks decorations from that set. Only the decorations, though; FVWM-Crystal does much more that I didn’t want. Here’s how I did that:

# FVWM-Crystal decorations
Read fvwm-crystal/fvwm/components/functions/Keyboard-Modifiers
Read fvwm-crystal/fvwm/components/functions/Window-Basic
Read fvwm-crystal/fvwm/components/functions/Window-Buttons
Read fvwm-crystal/fvwm/decorations/Clearlooks/Default/Theme.windows
Read fvwm-crystal/fvwm/components/decorations/Buttons-windows
ImagePath $HOME/.fvwm/fvwm-crystal/fvwm/icons/Default:+
Read fvwm-crystal/fvwm/components/styles/Application-Icons-22-32

Style * Font xft:Verdana:pixelsize=12:Bold

# Borders don't exactly look right with Clearlooks.
# Style * BorderWidth 3, HandleWidth 3
# # The title bar pixmap used in Clearlooks has a gradient, slight
# # though it may be.
# Colorset $[cs-window-inactiveborder] Background "#f1eeea"
# Colorset $[cs-window-activeborder] Background "#627d8f"

I change the font style because theirs wasn’t quite right (maybe it used a font I didn’t have, I can’t remember). You get an error about a missing function named Include but you can ignore this. Note that I did have FVWM-Crystal installed (well, copied) in ~/.fvwm/fvwm-crystal.

One slightly ugly thing about FVWM is the fact that you can’t apply themes to different parts of the window border. For example, you can’t set the “lower left handle” independently of other handles (A.K.A. corners) or sides of the border. I don’t even think you can turn off parts of the border. To make your windows prettier, the FVWM-Crystal Clearlooks theme (as well as others, such as Mist) simply set the window border to one pixel and make it some black or gray color. This looks OK (when you have two windows next to each other, you see two pixels of what looks like black, which is kind of odd looking) but it also means you have to get the mouse right on that one pixel border in order to resize a window. A fast way around this might be to just make a binding to put FVWM in “resize window” mode, rather than try to aim at that tiny border.

FVWM is very configurable, and it’s still actively developed, both of which are big deals in my book. FVWM is usable as a window manager for KDE and Gnome. (P.S.: change your window manager in KDE by setting the KDEWM environment variable in your ~/.bashrc.) Despite all of its configuration options, though, there still appear to be no good way to have windows become focused as you cycle over them! When the window list is displayed, you can’t have another window become focused. This makes some amount of sense, of course, since WindowList could possibly take input (hot keys to jump to a particular window—though I don’t think these work when you’re using Alt-Tab and SelectOnRelease). I think what happens is the window list does a grab, and any focus events are queued until the window list ends its grab. I tested this by starting something like sleep 3; FvwmCommand WindowId 0x1234567 FlipFocus in a shell, then opening the window list. Nothing happens until you close the tab box, after which window 0×1234567 takes the focus.

You could almost get the behavior I’m looking for by bypassing the window list (which is fine with me) and using Next to accomplish my goal “by hand.” Trouble is, you need to use Next Focus as you press Tab, and then detect when Alt is released and use FlipFocus to move that window to the top of the MRU stack. FVWM doesn’t tell you when Alt is released, only when it’s pressed. I actually started hacking support for something like a KeyRelease command that would call a function when a key was released, despite some discouraging comments I happened upon on the (active!) FVWM forums. I was kind of flustered at having to do all this, though, and I think I ran into additional theoretical obstacles that made me eventually give up and go looking for something else again.

I’ll note one person claims to have achieved the behavior I want in FVWM. However, PipeCommand? That looks icky to me (though I’m sure it works, why do I have to start a shell when I hit Alt-Tab?) and he mentions there may be a problem or two with it.

---

I tried some other window managers. Openbox looks OK, but it doesn’t have the behavior I want and it looks less configurable than FVWM or wmii. Honestly I’m not sure what the advantages of this window manager are. Maybe it has a small memory footprint or something. I do know that it has configuration files in XML, which makes the baby Jesus cry; further, its schema uses elements where it should use attributes IMHO, which can mean lots of unnecessary typing. There is ObConf to get around some of that, but when you want to start configuring, you’re going to be writing XML. Ew.

I tried Enlightenment 0.16. Didn’t have the behavior I want. (I didn’t know that Enlightenment was originally based on FVWM! Or so I read on the Interwebs.) I tried Enlightenment DR17 (or 0.17 or whatever) and it didn’t have the behavior I want; in addition I found out they’re no longer concerned with making Enlightenment work as a window manager in Gnome/KDE, so it’s definitely out.

So that’s kwin, wmii, FVWM, Openbox, and two versions of Enlightenment. You can count Metacity if you want, though I haven’t tried the version in FC5. (I have no reason to believe it has what I want, nor an easy way to get what I want. Metacity developer(s) are against lots of features; I think their motto is “just learn one way and live with it,” and I mean that in the least inflammatory way possible.) What do I come back to?

Sawfish, of course.

Yes, the same window manager I’ve used and loved since probably the first time I tried a “desktop environment” (Gnome). I was touched in the most sensitive places on my body by the large, nearly overwhelming number of configurable options—and that was just in the GUI! I didn’t even realize for some time that lots of Sawfish is written in a Lisp-ish dialect called librep allowing for even greater customization, should you desire. Truly this must be the Emacs of window managers. (I’m grinning at the people who think that’s a curse rather than a compliment.)

I gave up trying to make Sawfish work when I first installed FC2. librep and rep-gtk no longer compiled correctly (at least from their old RPMs) and sawfish-ui wasn’t working right. On FC3 or FC4 I think some windows (such as the notorious XMMS) stopped working right; I don’t remember what that means, but I suspect something like disappearing windows or windows that won’t ever take focus.

After all this window manager masturbation, I was so forlorn that I opted to try and make myself even sadder by compiling Sawfish and watching it fail. I first started out by trying sawfish-mmc. I think this is just a version of Sawfish that some kind soul has been working on to perhaps add features, or fix bugs. I’m not really sure. It didn’t exactly work right: spammed lots of debug stuff, when I tried to turn that off I got a core dump, etc. To the sawfish-mmc developer: please don’t stop working on Sawfish! I’d like to see it become much more active in hopes that it stays alive until something better comes along to replace it. However, the “mmc” version was not for me at this time. (I think the author even notes that it’s currently unstable whilst he plays with new features.)

Instead I checked out librep, rep-gtk, and Sawfish from Gnome CVS. (Don’t bother with SourceForge; they’re having CVS problems again I think. In fact, let that statement be heard by every developer: don’t bother with SourceForge.) (I’m sorry if I sound bitchy about a free service that some people might like, but it seems like SourceForge is down half the time I want something from them.) After a minimal amount of prodding, lo, Sawfish was started. And it worked!

I got the Crux theme by default. I put in my old ~/.sawfish/custom file and I got all my settings. sawfish-ui (the configuration tool for Sawfish) works! It has less options than I remember, but for now it has everything I need. And… and… I have focus on cycle! Truly it was “Good Friday.”

So now I’m working with my Sawfish build as my window manager. I’m going to see how it goes. So far, nothing weird has happened. Well, except for this mysterious, transparent system tray icon I have: no name, not visible in the tray, and it only has a generic X Windows icon associated with it. I don’t know whose fault that is, though. (The KDE laptop battery monitor was having some trouble starting up, too. P.S.: that thing needs a “percentage left” display like Gnome has.) I’ve even written my first Sawfish customization in librep. I wanted a “Send to desktop” menu on window operations like kwin gives you:

(define (darkness:send-to-workspace-menu window)
  (let* ((limits (workspace-limits))
         (number-of-workspaces (1+ (- (cdr limits) (car limits)))))
    (do ((workspace-number 0 (1+ workspace-number))
         (menu nil))
        ((>= workspace-number number-of-workspaces) menu)
      (let ((menu-string (format nil "Workspace _%d" (1+ workspace-number)))
            (action (lambda ()
                      (send-window-to-workspace-from-first window
                                                           workspace-number))))
        (setq menu (nconc menu (list (list menu-string action))))))))
(rplacd (assoc "_Send window to" window-ops-menu)
        darkness:send-to-workspace-menu)

That’s from my ~/.sawfish/rc.

Surprisingly, many shortcuts I had set in kcontrol, but attributed to kwin, still work in Sawfish. For example, the key I bound to start konsole, and Alt-Esc to bring up the “Run Command” dialog. That’s perfectly fine by me, so long as they work. (In fact, it might even be considered nice to maintain as many shortcuts as possible in one place, namely kcontrol.)

So once again: Sawfish fucking rules.

I’ll add that I put all the window manager-related packages I’ve made for FC5 up at http://www.codefu.org/people/darkness/fc5-packages/. Sorry if they’re a bit inconsistent, and I suspect I have left out a few Requires/BuildRequires as well.