RE: Nine Improvements Needed in KDE, by Bruce Byfield

Dear Bruce ..

Thanks for trying KDE 4.0.x and then writing about it. It's always great when people try something for a while and then give their honest opinion on things. I'd like to address some of the issues you raise, so let's start where you started:

"A more customizable panel": the issues you note, from resizing and moving to not covering the toolbox, are already addressed in svn with the exception of autohiding which is currently partially working in a WIP patch. So this set of issues is more past tense than anything at this point. There remain some burrs to work out, such as not all widgets accommodating really small panels very well still or easy moving of applets.

"A better menu": This one is less clear. You state that it seems to be based on the XP/Vista menus, yet other than having a header and a footer I really don't see many overt similarities. Vista introduced integrated search, but that's a no-brainer. Kickoff isn't a two-pane model, it has tabs .. I could go on. Certainly they are more similar with each other than, say, the MacOS alternatives and Kickoff, but that's a bit broad. In any case case, kickoff concepts were usability tested. There's always room for improvement, however.

The sliding menus thing is indeed one of those areas I'm not happy with; the rest is a marked improvement. It seems you agree. It also seems you agree with me that the old style menu sucks even more. ;) An approach I've started on to improve the menu navigation is to provide a breadcrumb control to the top of the menus. Hopefully I'll have it completed for 4.1, but I think it will largely take care of the issues you note about quick subnavigation.

But let's get really serious here: trolling through their installed apps randomly is hardly something most people do on a regular basis. If they are, we should ask ourselves "why?" because it certainly isn't what most people are wanting to do. Therefore it isn't what one should be optimizing for; indeed we should be offering better ways of getting at those things. Integrated search, favourites, and krunner's flexible searching (and not just by name, either) are all parts of the answer here.

Moreover, plasma provides the flexibility for alternatives to appear rather easily. We already have two menus in kdebase, which is one more than in kde3, with Lancelot in extragear and other experiments underway elsewhere.

"Remove the mini-icons": Ah, the infamous "call for removal". This has got to be one of my personal pet peeves. The answer to "could be better" is not "get rid of it"; well, unless one is completely happy with never improving or innovating. Since we're in the hi-tech industry, which has been all about radically changing the world for the last 50 odd years, the answer to that should be pretty obvious. So rather than "toss it", let's look at your issues and see what might be done about things.

"these mini-icons are not supported equally by all icon themes in every distro": Yep, many icon themes suck. Improve the themes. It's absolutely daft to suggest that even though we have working solutions (e.g. Oxygen, to name but one) that we should therefore tiptoe about and ensure our software sucks in other ways. The whole "must work in every possible contrived scenario" thinking is just not something that jives with the real world; with Free software there are too many scenarios, particularly contrived ones, and I'm not satisfied with being held back by the failings of others (e.g. incomplete or outmoded icon themes). This is one reason companies like Apple continue to shine in areas we don't: they control everything so can create optimal scenarios; we need to find the happy medium between "control everything" (uck!) and "let the mediocrity that comes with 'allow everything' set the height of the bar". No, set a bar and let others rise to it. That's a recipe for improvement.

"they can be hard to pinpoint with a mouse-click" That I agree with. We're actually going to be looking at how to re-work the applet handles this week at Tokamak, the first international Plasma developer sprint being held in Milan. I'll keep you posted. ;)

"add an appearance of complexity that may intimidate new users": If one makes usability statements, it's best to match them with testing (which isn't surveying, btw) or research others have done in relevant areas. The "may do $BAD_THING" is just so impossible to discuss because of the "may" and lack of any supporting data. I will note that it's one aspect that we haven't had any negative feedback on during user testing or in our issue tracker. Neat.

"redundant when each icon already has a right-click menu with the same choices.": So tell me which finger is right click on a touch screen? ;) Context menus are also "hidden" functionality: people learn to try and right click on things to see if it brings up anything useful. This is daft. Context menus should be there to house less used or more difficult options; hover interfaces make things obvious and discoverable. They also work with out a multi-button input device. Such as a stylus.

"They serve no useful purpose, and wouldn't be missed if eliminated." You may not think so, but others would differ. I'd also humbly suggest that clicking on and manipulating a resize button is more intuitive and "feels better" than "right click, select resize, move the mouse about, $DO_SOMETHING (click?) when done".

Let's move on ...

"A preview for images in the file manager": There's a Preview button in the toolbar, apparently ou missed it or it was missing for some odd reason in the build you installed. But it's there, and in 4.1 it's even nicer with cute little frames around them.

"Improved accessibility": I'm really, really disappointed in this section. Why? Because an insane amount of effort went into making sure that Qt4 works with with AT/SPI. Trolltech invested in a stack of tools to make working with D-Bus painless (and then some!) and then used those tools to create a backend for QAccessible on X11. You can read about it here on Trolltech's docs website. This was not a small amount of work and it was done because we believe in accessibility (a11y) so much.

KDE and Qt have both been very actively involved in a11y efforts for a number of years now. We hosted an a11y summit at Akademy in Ludwigsberg, Germany some 4 years ago, we've worked closely with the FSG a11y group, attended conferences around the world, adopted specs such as the X11 a11y key controls and wrote UIs for them, included numerous tools in KDE to work with these things and also taken the position that rather than duplicate every tool just because it isn't written in Qt to try and add new tools that are missing so the entire count of Free software tools by genre increases. Top this off with the work to bring a11y support on X11 up to par with what we've had on Windows and Mac in Qt for years ... it's significant.

So given both our long term interest and long term efforts that have impressive real world results .. I'm not sure a lecture on the importance of a11y, or misleading the public who reads your column to think KDE doesn't do much in the area of a11y, was warranted.

"What it lacks is an extensive screen reader like GNOME's Orca": Do you really think our time is best spent spending time reimplementing Orca just so we have something in Qt? Maybe someday someone will, but right now we have better things to do. This kind of mentality of "my toolkit or DIE!" is a disease. It makes us waste more effort and time when it isn't specifically needed. In this case, just use Orca with KDE4 apps. That's why there is AT-SPI: the bridge these gaps between Gtk+, Java, OO.o, Qt, KDE, etc...

"Drag and drop between menus, the desktop, and the panel": This is already done in svn, and not just limited to files. Rejoice! =)

That's a significant point as well, because the whole "desktop is a place to shove icons representing files" is limiting and largely redundant. What if I want to show more than one directory on my desktop? What if I want that directory to change depending on what I'm doing? Icons are demoted in Plasma to being just like any other widget, and in 4.1 we're about to replace the "desktop icons" with a simple yet much more common (and flexible) folder view.

"A broader selection of widgets": I'm not sure what you were trying to say here, other than to point out that a widget system that is only a few months old has fewer add-ons that one that is years old. I should hope so, otherwise the years old one is a complete and utter disaster. I also don't see the point of the comparison to tomboy which is rather out of scope.

That said, I currently count nearly 60 useful widget (so not counting test widgets or Hello World style widgets) in my Plasma install, and I don't have all of them. Then there is SuperKaramba which has dozens and dozens of its own. In 4.1 there are also the MacOS Dashboard widgets. So this really starts to look a bit silly =)

I'd also suggest comparing what does exist, such as the Twitter Plasma widget versus what's available elsewhere. Even though just released a couple months ago it's already nicer than what I've seen elsewhere. In fact, I know one person who switched to KDE4 from another system specifically because of that.

"KDE 4's one innovation is to permit larger version of widgets that fit on to panels on the desktop." I think that sells the rest of KDE4 short. I mean, I look at what I see in Phonon or Marble or Dolphin's nepomuk integration or ... Perhaps you are confusing "KDE 4" with "the desktop shell". Even then, I hadn't seen the desktop grid effect anywhere (to name one) not even in Compiz before KWin4.

That said, if we do want to focus just on Plasma, let's look at the pervasive scripting, the division between data provision and visualization, the inclusion of a plugin based "UI command line" with the default desktop command dialog, Containments, the use of SVG for the desktop, a properly composite aware free software shell, the ability to easily slide the same interfaces between devices of radically different scale ... I won't even mention things we don't have more fully realized such as zooming and activity-centric layouts, though that brings me to:

"why clutter your desktop with minor applications that you only occasionally want?" Well, Bruce, the answer is you don't have to. You can have nothing on your desktop whatsoever. For those who would like to build sets of tools that aid in the task they are currently working on (remember you can pull then forward by pressing Ctrl-F12 as well), it means the world. As more task oriented widgets becomes available for things like IM and presence integration, the folder listing I mentioned earlier, sharable (i.e. zeroconf aware) regions, more online data agregators ... This becomes more and more compelling.

Or we could talk about the "media center" concept. I hear it's getting pretty popular. ;) Plasma provides a way to have a widget assembly that can come and go and provide access to exactly that set of features and functionality. Yes, you may only occasionally want to skip through your film and video collection, but having the ability to call up that interface with a couple clicks is exactly what most people want to be able to do these days.

So I think you not only got the conclusion wrong, but your whole premise ("clutter your desktop ... minor applications") is askew.

"Better organized configuration tools": I'm not sure how you installed KDE 4.0, but your description of the layout of things is not what I have here. Odd. As for palm pilot and mobile phones being applications rather than control panels, that's always been the case; those are interactive tasks rather than simple configuration issues. For syncing, I'd like to see a Grand Unified panel one day, and I do agree that there is room for improvement in the ordering of things in System Settings yet. I just don't find what I'm looking at here, as a from-source install of KDE4, matching up with what you're describing.

"One of the advantages that KDE Classic had over GNOME was an initial wizard that allowed you to choose in a matter of seconds how much eye candy you wanted to run.": Interestingly, the majority of the user data we culled, including from "commercial" sources such as distributions, implied that this wizard was rather hated. It had other technical issues inherent to it, but really the first thing someone wants to do when they log in is perhaps set up their email/IM and get some work done; it's generally the tweakers (and reviewers tend to fall into tweaker mode, btw, even if they aren't tweakers in real life) who fall into the "let me tweak configuration values first!"

"font anti-aliasing, is not nearly optimal," Fonts are a difficult point right now. If you wish to wag fingers over fonts, go talk to the Free OS vendors who can't seem to get a consistent set of fonts between them, or a consistent set of font management capabilities for that matter. We are still at the mercy of the final system integrator when delivered as binaries for a given OS while we deal with a system of multiple moving targets on the source code front. It's not pretty, and I don't think the gains are to be made at the application level but in the infrastructure and OS vendor levels.

"Improved interface word choices" Here we agree; there's lots of room for improvement here, though things are already pretty decent. However, I think your examples were really poor.

You mention "sub-pixel rendering" as if that was out in the open somewhere. Instead, you can only find it once you go into the Fonts control panel (the integrated search there is nice, isn't it?), select "Enabled" instead of the default setting of "System defaults" (meaning "Let the people who knew what they were doing define what it should look like") and then click on the Configure button that becomes active next to it. Trotting that out as an example is a little inane, don't you think? I'd also ask you what you think a better term for that feature would be.

The "Setup Samba relisa and the ioslaves" is a good one, though I had to search for it a bit. It's a heading in the Sharing control panel in "Network & Connectivity" where the main tab says "Windows shares". I doubt that phrase therefore actually stumped anyone, but it's certainly odd and out of place. Thanks for pointing that one out, I'll commit a fix for that as soon as I'm done with the blog entry. (See, who need a bugzilla? These days we have the power of blogs ;-p )

Then you say: "the new KDE insists on calling its new applets "widget" -- a term that will sound vague to lay users, and inaccurate to developers for whom a widget is part of a graphical interface." Let me point you to "Apple Dashboard Widgets" or "Yahoo Widgets" or "Vista Widgets" or "Opera Widgets" ... I could go on, or diversify with entries like or "Google Gadgets", but you get the point. Widget has become a term that refers to exactly what we're doing. "Applet" may be known terminology to Java developers and KDE/GNOME users from years past, but Wiget has far more broad traction especially for this class of items.

As for "inaccurate to developers" perhaps you can find the developers who got confused or even care about it. Maybe Apple, Yahoo, Opera and Microsoft would like to know about those people too.

Moving on:

"KDE's habit of referring to both an application and its function in the menu": .. which is why we separated them very clearly in kickoff.

But all quibbles aside, you close with:

"All the same, mentioning what needs to be improved remains worthwhile. Improvements are more likely to be made if people are urging them ..."

I agree. Let's just not fall into the "therefore I need to be overtly negative at every turn, and screw the whole factual accuracy thing" trap in the process. I also hope you don't mind, Bruce, having your list of possible improvements dissected and reviewed in turn with equal voracity

I do also agree when you say:

"the question should not be why it needs so many improvements so much as how developers managed to make so many changes all at once"

It constantly amazes me as well. My answer to the question would be: a bit of daring, a measure of guts, an awesome community and a whole lot of freedom. =)

Finally, you say:

"Still, until KDE 4 settles down, potential users should be aware that it continues to be a work in progress, with a large share of unfinished features."

This is well in line with our guidance for 4.0 and somethine we've tried to make clear, so thanks for getting the word out. Until 4.1 (or 4.2 for certain use cases) arrives, there's always KDE3 which is still alive, kicking and a great work horse. For those who are early tech adopters or software developers, 4.0 is a great entry point, but it's certainly not for everyone at this point.

Again, thanks for taking the time to share your thoughts on things, and hopefully those reading this will now have a bit more of the whole story as well.

Cheers,

Aaron Seigo.