jmoiron.net

Perfectionists may never let Linux be ready for the desktop. I don't think its quite there yet, although projects like Ubuntu have me a little hopeful. Still, what projects like Ubuntu and SuSE and the like do are iron out all of the irritating inconsistencies with their own set of standards. It usually works alright, but patches sit around for a long time, even in central packages to important projects:

**Do you want me to merge these packages?** [Yes / No] yes
>>> emerge (1 of 1) gnome-base/gnome-session-2.12.0 to /
>>> md5 files   ;-) gnome-session-2.12.0.ebuild
>>> md5 files   ;-) gnome-session-2.10.0-r3.ebuild
>>> md5 files   ;-) gnome-session-2.10.0.ebuild
>>> md5 files   ;-) files/gnome-session-2.10.0-esd_switch.patch
>>> md5 files   ;-) files/Gnome
>>> md5 files   ;-) files/gnome-session-2.8.1-hide_splash.patch
>>> md5 files   ;-) files/gnome-session-2.6-schema_defaults.patch
>>> md5 files   ;-) files/gnome-session-2.10.0-schema_defaults.patch
>>> md5 files   ;-) files/gnome-session-2.10.0-no_smproxy.patch
>>> md5 files   ;-) files/digest-gnome-session-2.10.0
>>> md5 files   ;-) files/digest-gnome-session-2.12.0
>>> md5 files   ;-) files/digest-gnome-session-2.10.0-r3
>>> md5 src_uri ;-) gnome-session-2.12.0.tar.bz2

This is just Gentoo, who patch somewhat lightly compared to the more integrated distributions. Patches on a small but integral piece of GNOME have version numbers that are 2 or 3 major revisions old. Patches get put on hold momentarily or indefinitely, because whoever feels they aren't important enough or that they are traveling backwards. Look at how many people had to patch in options for removing spatial when the GNOME devs were shoving it down everyones throat and telling them that if they didn't like it they were foolish.

This is a real problem in oss, and on the Linux desktop in particular. Few are ever happy, because there are simple but distracting mistakes with all desktop environments. Look at any screenshot of xffm, or Konqueror's default font selection, or any number of problems with GNOME that distributors have been fixing for ages. If everyone is changing your defaults (like spatial nautilus, or half of the settings in kcontrol, or using rox in xfce), then your defaults are probably terrible.

This semi-ranting all comes from a single but festering, annoying data point that I decided to finally just learn and fix: mouse cursors in X. Translucency, drop shadow, and animation was provided by Xfree86 4.3 in February of 2002, making the feature almost 4 years old. Software controlled cursors were available before this, but most developers felt that not having these effects was too limiting, and many of the cursor themes were basic or over-detailed. Now, with several professional looking original and cloned variants, attractive cursors are easy to come by. Since a user is going to be staring at the cursor a lot, since its one of the primary pieces of the interface, its a nice touch to make it attractive.

But setting mouse cursor themes isn't instantaneous; X has to be restarted (which might as well be a reboot, since it completely interupts work flow). Changing the setting in the first place is a little complex unless you run KDE or GNOME, and even if you do your theme will most likely be installed incorrectly. Why?

There isn't any real coherent, standardized naming convention for X cursors. What you say?! Well, there isn't a followed convention, and there isn't an existing one that is well formed and outside of draft status. Various applications who want to change the cursor to signify different things to the user ("I'm busy", "Ready", "Waiting...") get to call their cursors by names which may or may not be there. KDE's approach? Use hashes.

00008160000006810000408080010102 -> sb_v_double_arrow
028006030e0e7ebffc7f7070c0600140 -> sb_h_double_arrow
03b6e0fcb3499374a867c041f52298f0 -> crossed_circle
08e8e1c95fe2fc01f976f1e063a24ccd -> left_ptr_watch
14fef782d02440884392942c11205230 -> sb_h_double_arrow
2870a09082c103050810ffdffffe0204 -> sb_v_double_arrow
...

What exactly these hashes are of I couldn't quite figure out; perhaps its some X resource that is more a part of the API than of the theme interface. In any case, many KDE applications won't use the right cursors (and thus, default to the core theme) if you don't have these symlinks set. The one that was particularly disruptive was the default "hand" cursor, which in core theme is large and unwieldy, and has an odd sensitivity that makes you lose the exact point of your mouse. This cursor is ever present; on any link or icon in the entire interface.

Naturally, this is an easy thing to fix. The obvious solution is to standardize on something human readable; ie. not a hash. It would even be mostly sane to standardize on the names used by GNOME, or any set of names really, and then proclaim loudly that you are using this standard. What's a good user to do? File a bug report, of course.

Look at the discussion in the bug report. First, people don't know why the problem exists. This might be because they have long fixed it, or because they have packaged KDE themselves in a way other than what the releases have. In any case, when they realize its probably because of the hashes, the answer is "You do not have the propper hashes set in your cursor theme." How do you get these hashes? XCURSOR_DISCOVER=1 konqueror;; Bug Resolved.

Is it resolved? Shouldn't things like this, and the fact that 1/3rd of the discussion posts are duplicate bug entries, show that perhaps the bug isn't fixed? This situation shouldn't happen; if you are going to go all neato cool with hashes for filenames, then your mouse installing program needs to make a good effort to create the right links. It's something that would make things better, that would alleviate the troubles of many people (I'd immagine that it's a very generous estimate to say that 1 in 100 people who experience a problem will make a bug report). It's something that would be good for KDE's junior jobs program. And it's something that will remain unfixed because stubborn KDE developers who have decided to run with a terrible solution don't want to even admit that it should be done right instead.

With time, FDO will standardize a lot, and hopefully interoperability will reach new highs. But the next level, integration to the Kparts level, probably won't ever happen. The desktop will either be fragmented, or application programmers will be burdened with impossibly complex interoperability standards.

In an unrelated note, I spent some time at work playing with the google maps api.