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.