Showing posts with label kde. Show all posts
Showing posts with label kde. Show all posts

Saturday, May 01, 2010

Kubuntu Lucid and KDE 4 reactions

Speaking of how software makes you dependent on other people, the newest Ubuntu Long Term Support (LTS) release just came out. This means that in a year, support for the previous LTS release will wind down; which in turn means that Ubuntu users must upgrade sooner or later, unless they want to sacrifice security updates and compatibility with new releases of third-party software.

So, I took the plunge: yesterday I downloaded and installed Kubuntu Lucid.

This is the first Ubuntu LTS release that runs KDE 4, the latest major revision of KDE. I've been using KDE for about 11 years, ever since version 1.1. My immediate reaction was simply that KDE 4 is a mess. And after playing around for a few hours, tweaking settings, and trying to settle in, I still think KDE 4 is a mess. As I use it more, I'm not settling into it; I'm simply accumulating more irritations.

Without exhaustively listing all the details, my complaints basically break down into three categories.

First, there are pervasive performance problems. In every corner of the UI, "shiny" effects have been prioritized over responsive, performant interactivity. To take just one example, under KDE 3.5, the Amarok media player used to be super snappy and responsive; it left iTunes or Windows Media player in the dust. In KDE 4, Amarok takes a couple of seconds to expand one album or to queue up songs, and resizing UI panels is painfully slow and janky. (My workstation has a 2.13GHz Core 2 Duo and a good graphics card. This should not be happening.) Similar problems can be observed in the desktop panels, file manager, etc.

Second, in general, the UI changes seem designed to push KDE's new technology into your attention space, rather than getting out of the way so you can accomplish tasks. Again, here's just one example: in the upper right corner of the desktop, there's a little unremovable widget that opens the "activities" menu:

The upper right corner of the desktop is a hugely valuable piece of screen real estate. By placing this widget in the upper right corner, the developers are signaling that this menu contains operations which will be frequently accessed. Do they really think users will add new panels to the desktop frequently? (For non-KDE users, a "panel" is KDE's equivalent of the Mac OS X dock or the Windows taskbar.) So far, almost every time I've clicked this widget has been by accident while trying to close or resize a window.

If you're a desktop developer who wants to show off your technology, this design may sound good: you put this menu there to make sure users discover your desktop widget and "activities" technology*. However, if you're a user, then this menu mostly gets in your way, and you wish it were tucked away somewhere more discreet.

Third, the KDE 4 version of every application has fewer features and more bugs than the KDE 3 version. The "Desktop" activity no longer has a way to "clean up" icons without repositioning all of them in the upper-left-hand corner. The Konsole terminal application's tab bar no longer has a button from which you can launch different session types. The list goes on.

Anyway, of course, I don't pay for KDE, and so in some sense this is all bitching about free beer. However, suppose I did pay for KDE. Would I have any more input into the process? Windows users pay for Windows; if you don't like the direction Vista and Windows 7 are taking the UI, do you think you personally have any chance of influencing Microsoft's behavior? Mac users pay for Mac OS X; if you disagree with Steve Jobs, do you have any chance of influencing Apple's behavior? In fact, you do not, and both user populations have experienced this reality multiple times in the past decade. Mac users loved the Mac OS 9 UI but they had to give it up when Apple stopped supporting it on new Macs. Microsoft users who are attached to the Windows XP UI will likewise be forced to give it up eventually, when Microsoft stops sending security patches.

The KDE 3 to KDE 4 transition is simply KDE's version of the OS 9 to OS X transition, or the XP to Vista/7 transition. Except that those seem to have worked out OK in the end, whereas KDE 4, which was released over two years ago, seems to have lost its way permanently.

I'm writing this post not just to point out KDE 4's defects — I mean, it feels good to vent, but who really cares — but also to marshal further evidence in support of my contention that owning software doesn't mean much anymore.

Even the fact that KDE is Free Software means little in this case. I mean, what am I supposed to do now? I can't stay with the previous Ubuntu LTS release forever, unless I want to expose myself to security risks, and also be unable to run or to compile new software, both of which are deadly for a software developer. Conversely, I can't singlehandedly maintain a fork of the KDE 3 environment forever; this guy's trying but without a large and active community behind the project, it's doubtful that it will remain current for long. And frankly, I'm getting older, and I don't have enough time to invest in both hacking around with my desktop environment and also accomplishing the other things I want to accomplish in my life.

So, I can either (1) suck it up and live with KDE 4, or (2) abandon the desktop environment I've grown to love over the past 11 years, and jump ship to GNOME or something. (Right now I'm leaning towards (2).) Adopting software means making a calculated bet on the behavior of other people. And sometimes you lose.


*BTW "activities" are 80% redundant with virtual desktops and therefore hugely problematic and confusing as UI design, but I won't get into that.

Saturday, February 28, 2009

Option key as Alt in KDE apps on Mac (Mac annoyance Saturday)

The default keyboard setup of Apple's X11.app for Mac OS X doesn't support Alt- shortcuts in KDE apps (at least not when KDE's installed via current fink, e.g. by sudo /sw/bin/fink install kdebase). This makes konsole just about unusable, as konsole translates Alt events into Meta keypresses on the underlying terminal, and discards true Meta events. To fix this, assign the keycodes as follows in your ~/.Xmodmap:

keycode 66 = Alt_L
keycode 69 = Alt_R

Then, ensure that your X11 "Preferences..." are as follows (dialogue box is from Leopard):

Finally, restart X11.

For completeness, here's the keyboard layout kcontrol module (you shouldn't have to do anything here, as these are the default settings):

Credit to this macosxhints.com post, which took an astonishing amount of searching to sift from the vast oceans of trash and non-working solutions that you get when you search for X11 issues for Mac. I post this in the hope that it will serve as more efficient Google-food.

(Background: I recently killed the hard drive on my ~2.5-year-old work MacBook, and so I've been reconstructing my work environment on the shiny new MacBook they requisitioned for me. Running emacs in a screen session on a remote Linux box is one of my most common activities, so having konsole with no Alt/Meta makes Mac usage just about unbearable. I could not for the life of me remember the magical incantation I did to fix Alt last time, so I literally spent about half a workday intermittently typing random permutations of "kde", "fink", "alt", "meta", "konsole", and "leopard" into my web search box. Blech.)

Monday, October 30, 2006

Weaknesses of non-dictatorial community software projects

As an inveterate user and observer of open source, I've read many criticisms of open source software development that simply don't hold water. This post is about one criticism that I believe does hold water.

In contrary to the straw man often erected by anti-open source pundits, most open source projects have a relatively formal management structure wherein one person or a committee exercises strong top-down control over the project's canonical source code repository. That dictatorial hand may be felt lightly or heavily, but at the end of the day decisions must be made, and priorities set, and the project will follow the dictator/committee's decisions.

(Or --- in the case of a fork --- not, but nobody likes forks and ultimately each half of the fork generally assembles some sort of management structure.)

However, not all open source projects have a dictator. A few projects manage to survive with only informal technical governance structures. The largest and most successful of these is probably KDE, a desktop environment. KDE has a number of associated formal legal entities responsible for things like legal and marketing issues, but the technical direction of the project is not managed by either a benevolent dictator or a committee.

There are good things and bad things about this. Here is one of the bad things: this KMail wishlist item has been in the bugs database since December 2000. It is the top vote-getter on the most requested features list. But nobody has tackled it. A couple of people have made gestures in the direction of implementing it, but no bug-closing patch has been committed to the trunk.

In an open source project with a dictatorial or committee-led governance structure, somebody would long ago have cracked some heads and gotten this feature implemented. In a commercial software project, open source or non-, some engineer would be assigned ownership of this feature; and goddammit, if that feature didn't get implemented and maintained, that engineer would be fired and the feature would be assigned to someone else. But KDE's headless. It's less like a mammal with a central nervous system than an enormous amoeba whose various pseudopodia ooze tropically in the direction of "developer itches" and "coolest implementation hacks" (hence the recent proliferation of "hugely ambitious infrastructure refactoring" subprojects like Plasma or Solid) rather than unsexy, annoying-to-implement features that merely provide value to end users.

Now, as a by-product of this process, you often end up with a lot of excellent software. I use KDE every single day, and on balance I prefer its interface to both Windows and Mac OS X for intensive use.[0] But this software process isn't rationally optimized to serve the end-user, and so there will always be these frustrating little blind spots.

Which isn't to say that commercial software processes are rationally optimized to serve the end user either, but that's another whole series of posts waiting to be written.

(See also: Bug 8333, Bug 55777.)

[0] Yes, that's right --- not the code, not the customizability, not the Free and open source license, but the user interface of KDE is preferable, for a heavy user, to either of the big consumer operating systems. Windows XP and Mac OS X ---especially the latter --- are both highly polished and acceptable for casual use. However, when I'm juggling several terminals, eight or nine Emacs windows, and a half-dozen Firefox windows, the extra features of KDE's window manager simply destroy even Mac OS X's. Ironically, some of KWin's best features were in the classic Mac UI, and were dropped in OS X. (I first got hooked on windowshading when I was an undergrad Silicon Alley web production intern, juggling BBEdit, Photoshop, and multiple versions of Netscape. Ah, the old days...) Other features, like window gravity, have been pretty standard in Unix window managers for years, but have somehow never cracked consumer OSes even though they seem like no-brainers.