The most visible feature of this release is that it completely broke my keyboard layout. Nicholas Petrely and others have already commented harshly upon this release. While I like the "spatial nautilus" feature that Petreley and others have complained loudly about, and I agree that he should have done his homework just a little better, maybe by clicking on the "Applications" menu, I do think that there is an upsetting trend in GNOME development; the GNOME developers see themselves as the final arbiters of the user's desktop experience, and are trying to subsume all parts of X as part of their configuration. The switch from sawfish to metacity was the first step down this path, and others have been fast following.
Today's adventure was rooted in the new "Keyboard" control panel. Visually an appealing feature, there is now a "Layout Options" tab, which lets you fix a few of my favorite keyboard layout problems (control key in an inconvenient position, multi / compose key not configured on many keyboards, etc). However, there are options that are left out.
For example, I use a Mac keyboard, because it is the only decent scissor-action USB keyboard I can find. Macs have the odd habit of placing the 'alt' key in an unfamiliar location and the 'command' key (interpreted as the 'windows' key by linux) in the normal meta-key position. So I want to swap those because this is a very unpleasant finger-memory habit to be constantly correcting. Then, I would like to assign Hyper to the meta keys.
I did this with an
~/.Xmodmap file. Upon logging in to Gnome 2.6 for the first time, however, I was confronted with a pleasant dialog that alerted me to the fact that this was no longer supported, and I'd have to use the new Keyboard control panel. "Surely," I thought, "the ever-wise GNOME developers will have considered this case and provided an option for me in a handy new GUI control panel."They had not.
In fact, not only had they broken a standard X behavior, they seem to have gone to great lengths to make it impossible to correct. As I am "Advanced", I thought that I would use the "sessions" control panel to run a command upon login, at the right point (after the session manager proxy but before my window manager). No dice! This hangs the login process with no debug information, as it appears to be infinitely attempting to restart the xmodmap program and waiting for it to map a window.
Also, I can't run ~/.xmodmap in my ~/.xsession, because gnome-smproxy resets both any system-wide or any local xkb configuration changes. I think. I also couldn't find any documentation of this anywhere on short notice.
I eventually fixed the problem by inserting a shell script into my $PATH that looks like this:
glyph@kazekage:~% cat UNIX/bin/sawfish
#!/bin/bash
xmodmap ~/.Xmodmap
exec /usr/bin/sawfish $*
There is a lesson here, for GNOME as well as other developers.
DO NOT INTENTIONALLY DISABLE FUNCTIONALITY IN AN "UPGRADE" UNTIL THERE IS A REPLACEMENT AVAILABLE. In software development we call this a "regression" and it is why we have "regression tests", so that things like this do not happen.
I understand the new GNOME philosophy that this is a bug, and the correct solution is to fix the bug (by providing a more robust GUI keyboard-layout editor) and not to provide some kind of backward-compatibility hack that allows me to turn on ~/.Xmodmap again. However, the reality of integrated software is an ugly place. These kinds of hacks exist because it's really hard to re-implement functionality that's been around for ten or twenty years and do it correctly so you won't inadvertently break half of your users. And yes, in the UNIX world, you are much more likely to encounter heinous edge cases, weird custom hardware, and abrasive, know-it-all users than elsewhere. It's a niche where these sorts of things accrete.
I don't intend to call the GNOME developers names or insult their intelligence and motives as seems to be common when critiquing these decisions. Still, if they are interested in me (and the users for which I am sure I am a proxy here) using their software, they have to have a less cavalier attitude towards edge-cases and outside-of-GNOME configuration options.
These configuration options have real uses. Some examples: I use sawfish (and have sawfish depend on the hyper key) in part because I use the alt-tab key combination in emacs, which binds it to lisp-complete-symbol by default. I also have several keybindings useful for managing large quantities of windows, which Metacity is woefully inadequate for. What if you open every image on a website in GIMP and you want to iconify the resulting window group? Not only will this take you several minutes of real time thanks to the mandatory animation, it's not possible to do it automatically. You also can't tile or cascade just the group, shade them and stack them, move them all to the lower-left hand corner of the screen so that the close-boxes line up, or do any kind of batch window manager operation. It's the same bone-grindingly slow window management routine I've had to get used to on Windows - worse even than the Mac, where at least I have application groups provided by the OS.
All in all, I think that GNOME 2.6 is an improvement over previous versions. There was a lot of great work that went into it both from the GNOME developers and the Debian packagers who made my upgrade otherwise seamless. Still, I have yet to upgrade GNOME and waste less than 2 hours getting my configuration working again, though, and at some point the time consumed by constant maintenance of my setup and creation of gross hacks and workarounds is going to lead me to just run sawfish and fspanel or something.
Unfortunately, thanks to extremely tight coupling somewhere in the configuration framework, running with that light of an environment also seems to break all my GTK themes, so I have to make the choice between a working keyboard and a nice-looking desktop. Maybe I'll spend the two hours it takes to get a gtk configuration without gnome-session working at some point.
Update: there is a Debian bug and a GNOME bug already filed about this. Apparently it's equally destructive if you just happen to run one gnome application. To be fair, this is almost as much the fault of the XKB system as it is of GNOME. XKB seems to provide ten times the complexity of xmodmap, with none of the functionality. A quote from the documentation:
You can think of a group as of a vector of columns per each keycode (naturally the dimension of this vector may differ for different keycodes).
Naturally.