[Tag search]

Switching to Arch and XFCE

Tuesday 27 March 2012, 12:32

I am, as the title implies, switching my home desktop system from Slackware Linux and KDE to Arch Linux and XFCE. You may see some minor disruptions here (in particular, the astrological chart generator may be down or unreliable) for the next few days. The switch is a pretty big production; I've been using Slackware for most of the last 20 years, and KDE for most of the time I've been using Slackware, and because I've been doing continuous incremental upgrades instead of full reinstalls, some parts of my system actually are that old.

There was no one big annoyance or disaster to make me want to switch, but my dissatisfaction with KDE has been gradually increasing for the last few years, and I decided it would be better to switch in a controlled way when I'm not fighting a fire, rather than wait until some kind of disaster forces me to switch under pressure. I'm still basically satisfied with Slackware, and I could have continued to use it, but I tried doing a similar KDE to XFCE switch on my laptop first to debug the process, and found that doing a complete reinstall of the underlying Linux distribution really makes the desktop change a lot pleasanter. Given that I'm doing a reinstall of the core Linux system, it seems like a good opportunity to also do the switch to Arch, which has some advantages over Slackware.

Solved: Compose key doesn't work with SCIM, anthy, and Xorg

Monday 31 October 2011, 10:12

Posting this for the benefit of people who may have the same problem, and for my own future reference if it happens to me again.

The problem: Xorg (new name for XFree86) installation, configured with SCIM-anthy for Japanese-language input, and I want to also use the Windows keys as Compose keys when not in Japanese input mode. Compose and Japanese input both work in GTK applications, but in QT applications (notably, Konsole), Japanese input works and the Compose key doesn't. The Compose key is properly configured in KDE, xorg.conf (XkbOptions setting and UTF-8 locale), and xmodmap. If I disable SCIM entirely, then Compose works everywhere, but I lose Japanese input everywhere also.

New KDE, still broken

Friday 28 January 2011, 05:02

I see that KDE put out a new release on Wednesday. I'm disappointed that they still haven't fixed bugs 158556 and 180051.

Disabling Ctrl-Shift-Underscore font resize in Konsole

Saturday 23 October 2010, 10:16

Why is it that all my KDE-related postings seem to be about disabling annoying user interface misfeatures?

Today's has to do with the Ctrl-Shift-Underscore (Ctrl-Shift-_) key combination. This is used for "undo" in EMACS-derived text editors, including JOE. In recent KDE versions, Konsole has started trapping this key combination for "reduce font size." So you're merrily editing away, you try to use the undo command, and suddenly your font has become smaller. To make matters worse, it is a known bug that the key combination Ctrl-Shift-+, which is supposed to be "enlarge font size," doesn't work. So not only can you not undo editing changes anymore, but you can't undo the font size change either. Solution below.

Disabling search type changes in kiten

Sunday 26 September 2010, 13:08

The Japanese-English dictionary program "kiten" has an annoying misfeature whereby if you do a search that has no results, instead of saying there are no results it will automatically change the search type to try to get more results for you. For instance, an "Exact Match" search might be changed to a "Match Anywhere" search. Google does that sometimes (for instance, changing phrase searches to bag-of-words searches) and that's annoying too, but at least Google warns you when it does it, and the stateless nature of Google searches means that the change is local to a single search. With kiten, the search type change is permanent (even saved in the config file when you exit). That's a problem if you are doing many searches successively, for instance during translation, and you have to keep resetting the search type. It's an even bigger problem if you have the ill-advised, but default and encouraged, "Automatically Search Clipboard Selections" feature turned on: because then just selecting text in some other application can permanently change your kiten configuration.

Disabling huge-ass panel tooltips in KDE4

Sunday 26 September 2010, 12:40

Big news! I've finally achieved one of my most-wanted misfeature fixes with KDE4: disabling the ugly huge-ass animated tooltips in the panel. I think a lot of others wanted this as well, so I'm hoping they'll link here.

More on removing the desktop cashew in KDE4

Saturday 18 September 2010, 22:08

KDE4 introduced a stupid useless icon that you can't get rid of, in the upper right corner of the desktop. The developer of the relevant code has adamantly refused to introduce any possibility of making it optional; but a civic-minded third party created the "I Hate the Cashew!" "plasmoid" to make it go away. That's all well and good.

The bad news is that "I Hate the Cashew" is no longer maintained, and doesn't work anymore with the current version of KDE, 4.5.1 as I write this. The good news is that with some digging, I found a solution in a Web log comment from someone using the name "Newar," and that works. The trick: you can now move the cashew to your choice of corner. So move the panel out of the way temporarily (for instance to the left edge of the screen), move the cashew to a corner that will be covered by the panel (lower right), and then move the panel back to its usual location. The cashew is still theoretically there, but at least it's no longer all up in your face. Thank you, Newar!

For great justice

Saturday 18 September 2010, 11:37

I'm not planning to post further continuous updates on my move to the new computer, but at least one correspondent commented that she hadn't seen any further updates in a while and hoped the new machine was working, so I thought I'd better wrap up some loose ends.

The new machine works. It will be a long time before I'm fully "settled in" on it, and a lot of software that used to work, doesn't work now because of the change. I will be fixing things as they come up, one at a time. But I've moved over my home directory, email is flowing in both directions, and a snapshot of the old machine at the time of the crash is now archived to DVDs, independent of my other backup measures. I'm basically back in business. A few loose ends and other comments, below.

Disabling the "same directory as current tab" brain damage of KDE's konsole terminal emulator

Monday 2 August 2010, 20:06

So, you have a new laptop computer. You install the latest and greatest Slackware Linux on it, and it naturally comes with a newer version of KDE than what's on your desktop machine. You open the "konsole" terminal emulator as usual, work for a while, and then when you're ears-deep in /etc/acpi/events or somewhere, you open another tab and Whoa! you aren't in your home directory as you expected, your new tab is ears-deep in /etc/acpi/events or some such Godforsaken place.

Well, the first time you figure you just made a weird mistake and typed cd /etc/acpi/events/or/some/such/Godforsaken/place without realizing it (and then, fnord-like, didn't see the command in the terminal window), and you automatically type cd again to go where you meant to be and you carry on. But then it happens again.

So you resolve to lay off the crack pipe for a few days, grit your teeth and type "cd" again, and so it is only on the third time it happens that you finally decide maybe it's not just you, and you make appropriate experiments and discover the horrible truth: the KDE developers inflicted this on you as a deliberate feature! When you open a new tab it will pry into your bash process, figure out where you are, and put the new tab there to prevent your escape. Heaven help you if you weren't using bash.

That ought to be the end of the story, since they at least had the decency to put a check box for it on the "Edit profile" configuration dialog. Below the fold, what happens if you uncheck that box...