Disabling the "same directory as current tab" brain damage of KDE's konsole terminal emulator
Mon 2 Aug 2010 by mskala Tags used: kde, softwareSo, 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...
You uncheck the box and try opening some new tabs and it works, the new tabs open in your home directory where they should. You think you have exorcised the demon.
Then you close the window entirely - or open a new one. And it's back in full force. You try all reasonable steps and it's reliable: unchexure of the box doesn't get saved past the closure of the window. It always switches back to "Start in same directory as current tab."
Because you hope to spare others the experience, once you figure out a workaround you post it on the Web.
If the "Initial directory" box is empty, konsole displays this behaviour, automatically checking the "Start in same directory as current tab" box on startup even if you had manually unchecked it. The workaround is to make sure that box is not empty. I put a single tilde in mine, for "home directory," and it now works the way I wanted it to, giving me a shell in my home directory on every new tab.
Observed in KDE 4.4.3. Not observed on my desktop machine's installation of KDE 4.3.3 - it has both boxes, but accepts an empty "Initial directory" and unchecked "Start in same directory as current tab." without automatically re-checking the box.
I'm not going to try to file an official bug because I've been disappointed with the KDE people's treatment of two other bugs I'm interested in: tall bookmarks menus in Konqueror (they insist it's someone else's fault, make changes that do not fix it, and then mark the bug "fixed"), and fully manual hiding of the docking bar at the bottom (it existed in KDE3; now they demand "use cases" for why it's worth having, and suggest insultingly inadequate user-behaviour-change substitutes for just bringing back the functionality they removed). Both bugs have existed for many years without sensible resolution, and I'd rather the resources get spent on fixing them than on this one, which at least has a workaround.
4 comments
It always opens in the home directory, even though the checkbox in question is checked, and the path field is empty.
Debian, bash.
def0 - 2010-08-03 03:19
Matt - 2010-08-03 09:17
Seriously, it's hard to expect stability from any software project -- free or proprietary -- that can't be bothered to commit to basic practices like test-first development, and implementing that with automated test frameworks. I, at least, couldn't find any comprehensive test suite for Konsole; http://websvn.kde.org/trunk/KDE/kdebase/apps/konsole/src/tests/ is the best I came across. (You can probably get away with no automated testing if you're the sole genius on a project, but that describes approximately 0% of all software engineers.)
There's another bug lurking in Konsole that has to do with the way bold weights are synthesized for typefaces that don't provide bold variants. It has prevented me from using Inconsolata in my terminal, and has forced me to use what I perceive to be an inferior typeface. See https://bugs.kde.org/show_bug.cgi?id=226308. The ridiculous part (to me) is that they're trying to paper over the problem by offering a choice: do bold fonts render incorrectly? Then here's a checkbox to turn it off!
The Konsole developers' approach is ass-backwards. A developer should find the root of the problem and rectify the problem there, not defer the responsibility for fixing the error (the developer's error) to the users. Konsole can't render bold fonts probably in all common cases due to design assumptions that ended up not working out? Then it should not try to use bold weights at all until the design flaws are fixed.
That said, at least these are just annoying errors. At work I upgraded from Flex Builder 3 Academic to Flash Builder 4 Academic for a project, only to find that, going from 3 to 4, Adobe removed the profiler that was in 3. They will only provide that and other useful features (e.g. a test runner that can run subsets of tests and command-line building using Ant) if you shell over $350. For tools that have been available in other development environments since, uh, inception. For no charge.
That's not merely annoying; that's anatagonistic.
trythil - 2010-08-03 12:27
trythil - 2010-08-03 01:18