The week before last, Linux was starting to get me down. I just wanted stuff to simply work, rather than to have to do work to make it work. I got a lot of the gripes off my chest by moaning about them here on Sunpig, though.
The following evening, I nuked my SuSE install, put on Mandrake 9 for an hour or two, and went straight back to SuSE again. Seeing Mandrake made me realise just how much I had learned about SuSE since the start of October, and how much I would have to relearn to get as fluent with Mandrake. Not as much effort as moving from Windows to Linux, but it would still be infrastructural work, when my aim was to get started on the higher-level stuff.
(Reinstalling SuSE felt like a relief, which was odd, as I had just spilled my guts complaining about it. But that rant had also clarified for me the reasons I was persisting with my Annual Linux Experiment, and that was because I find it too hard to stomach Microsoft’s business practices. Moving to Linux is not easy in the same way that going vegetarian isn’t easy. After a couple of weeks, you start to get these cravings for bacon…)
After that I was fine again for a while. I was happy with my new-found conviction. Thomas C. Greene wrote an article in the Register on how to improve your fonts in Linux, and that helped a bit. (They still don’t look as good as they do in the screenshots, but they’re okay.) I got Apache installed and running–yay–and started doing some work on Movable Type.
It was while I was doing this that the next niggle jumped up: In Kedit (and every other KDE application) the cursor blink rate was very slow. And worse than this, the cursor would continue to blink while I used the cursor keys to move through a document.
This may not sound like much. So the cursor blinks slowly, so what? It doesn’t stop you from editing documents, it doesn’t mean that the cursor isn’t there–it’s just blinking slowly. Right?
Argh. Sometimes it’s the little things that make the difference between satisfyingly usable and mind-bogglingly frustrating. Because this isn’t as little a thing as it seems. If you write a lot (code, prose, whatever), you get very used to moving about a document with the arrow keys or control key combinations rather than using the mouse to reposition the cursor. It’s much faster to keep your hands on the keyboard, look up, and arrow-key the cursor to a new position that it is to move your hand to the mouse, find the mouse pointer on screen, move the pointer, click, then reposition your fingers on the keyboard. Not only is it slower because it takes more actions, I seem to remember some research that showed that different areas of the brain are active when you use the mouse and the keyboard. So your brain has to switch tasks as well. Not efficient.
Back to slow-blinking cursors: when the cursor blinks “off”, it is invisible. It is invisible for a significant fraction (more than half) of a second. During this fraction of a second, I can make several keystrokes, and move the cursor several times with an arrow key. But while the cursor was invisible, I didn’t know exactly where it was in the text.
Actually, the slow blink rate only masks the real problem. The real problem is that the cursor’s blink status really should be set back to “on” whenever you press a cursor key. This way, it is always visible when you’re arrowing through a document, regardless of the blink speed.
But could I find an option in KDE to change the blink rate, or the blink behaviour? No. Damn.
So I could guess that I’d got the cursor in the right place, and start typing again. This didn’t always work, and resulted in me having to go back and re-edit. Or I could wait whenever I reckoned that the cursor was roughly in the right place, wait for it to reappear, and then reposition if necessary. Or I could use the mouse to reposition the cursor.
All of these options are significantly slower than the way I’m used to writing. And because it was taking longer to go back and fix typos, or edit sentences, I found myself losing track of thoughts, and getting distracted. The speed at which I coded and wrote slowed down by much more than the amount of additional time it took to move the cursor.
A bit of Googling around found me a couple of newsgroup postings from people who were complaining of the same problem, but without any useful follow-ups. Non-KDE applications (XEdit, emacs) didn’t appear to have the same problem, so it looked like a KDE thing. Although I hadn’t installed it, the SuSE disks come with the Gnome desktop, so I tried firing it up. And lo, cursors in gEdit (and other Gnome apps) behave normally!
I could just use gEdit in KDE–even though it’s a Gnome app, the Gnome libraries are all installed, and KDE will quite happily fire it up. But I’d just got used to Kate, and gEdit doesn’t show a list of open files on the left hand side of the window. (There may be a plugin that provides that feature, but I couldn’t see one.)
As it turns out, some deeper searching through Google revealed that the cursor blink rate is not set by KDE, but by the underlying Qt libraries. And in fact, there is a little utility called qtconfig that allows you to set the cursor blink rate. Yay!
Setting the cursor blink rate to a low value (I’ve got it at 50ms at the moment) is almost as good as having it behave properly, i.e., resetting blink status to “on” at every keystroke.
Ah, but is there a way to make this happen? Well, it appears so. According to the changelog for Qt 3.0.5, Trolltech have fixed this version to “Reset blink timer when receiving a keypress event to keep the cursor visible during navigation.”
So…all I should have to do would be to upgrade my Qt libraries to version 3.0.5, right? Hmm. According to the YaST tool, I already have version 3.0.5 installed. Why, then, are my apps not behaving in the manner described? Dunno. But I’ve got the horrible feeling that solving this is going to involve grabbing the source for both Qt and KDE, and rebuilding both of them.
All this effort for a simple cursor blink. I’m craving bacon.