L

KDE 3.4

May 21st 2005 05:37:07

This is going to be part review and part open letter to KDE develpers. The install I evaluate is somewhat divergent from defaults, and indeed some of what I complain or congratulate on being fixed might be the result of the vestiges of old preferences.

The KDE team released KDE 3.4 a few weeks ago; the 4th major revision to the KDE 3.x series. The first in the series saw a switch to Qt 3.x and a dramatic improvement in look and feel without suffering the rewrite that plagued the first few releases of GNOME 2.x. KDE developers cite their usage of C++ as a slightly higher level language than C and the clean fluid design of Qt as reasons for the quick paced development of KDE, but whatever the reasons they have maintained for a few years a series of impressive incremental improvements on their system while keeping most of the decision making aperatus in public and away from corporate board rooms.

The most common gripe you will hear about KDE is that it is "bloated" or features too many programs. The incredible increases in speed with each of the last 3 releases (especially the last 2) have made it a somewhat tougher argument to make, especially as many of those who complain about the crowded feel of KDE are from the GNOME crowd; cleaner and simpler in interface but infamous for slugishness. This is not to discredit the claims, though; just because things work quickly does not mean you have avoided including unnecessary features in your desktop environment.

KDE has always had a kind of "proam" feel to it, and I do not think its just because the GNOME folks get more press in the human interface department. A lot of very cool ideas get implemented for the KDE community first, and are eventually considered interesting enough innovations that they are then ported to GTK+; an example is Karamba, which was (or had the feel) if a very nifty little hack for desktop widgets, and Gdesklets which was developed sometime later. Something going on today is KHotNewStuff (one of the most terrible names for a fabulous idea) which has been hailed as a good thing and is now receiving talk about equivalent inclusion in the opposite camp.

These innovations are not or seem not to be so carefully vetted; the interface with the latest greatest KDE technology tends to be subpar to whatever survives the grueling GNOME screening process, but I do not think that the desktop loses because of it; the K camp is good at figuring out what sticks, what doesn't, and what perhaps could use some more glue.

Konqueror

The crux of the KDE desktop is their browser Konqueror. KHTML is light (for a fully featured rendering engine) and feels snappy as ever; not quite so solid as Gecko, but you get the feeling from its performance and its footprint that you are making a tradeoff and not simply using an inferior product. Regardless of the latest somewhat illusionary spat between Apple and the KHTML devs it appears that KHTML has been making progress regardless of or with the benefits of Apple help.
I cannot comment on Konqueror's default interface, but I can say that it is fairly customizeable. For the most part (even though I think my installation had been paired down in a previous life) I still found buttons that I would not have use for, and I find switching between file browsing and web browsing to be somewhat jarring and clunky. Konqueror supports many, many protocols, and so its important to examine how the switch between these feels for the user. I've always found the Netscape way of browsing network file repositories to be more in line with what you'd expect from a browser; to drop into filebrowser mode for network file servers (using FTP or Fish, for instance) is a drastic change that leaves you wondering: "Whoa, where'd the Internet go."

One thing that does seem quite apparent is that Konqueror has too many menus. It is fast and slick but it feels as though its throwing everything there out on the table; not enough is done with context to hide useless options. Lets go through them one by one in the regular web browser mode.

Location

The "Location" menu has 16 entries, and really 4 of them (Open with...) are there for no particular reason whatsoever; if this functionality is really desired this can be a submenu or a hinted dialog (...). I do not see why, if "Save as..." and "Print..." are hinted at giving you a dialog you are presented with alternate "Save Frame As..." and "Print Frame..." options; but get rid of these and you have almost cut this menu in half. Every other program in the universe calls this menu "File"; location might make more sense but people for the most part are used to "File" and it is more concise.

Edit

The edit menu for browser mode should not contain "Delete", "Create New", "Edit File Type", or "Move To Trash". The rest of these options are pretty standard, depending on what "Properties" does (if anything).

View

Although they might proove useful in fringe cases I do not see the need for "lock to current location" and "link view" in web browser mode. If someone can explain this to me (a serious request) that would be much appreciated. Organizationally, I think that "Use Stylesheet" should be next to "Use index.html" (if both are indeed necessary or desireable; I don't know what "use index.html" is supposed to be). There should be a horizontal rule between "Stop" and the rest of the options to show the conceptual differece between controlling navigation and changing visual preferences. The other options on the menu are fairly standard for a web browser. I think its bad style to include "View" in the menu text (it is already the "View" menu) but this might be a computer science attitude and not a usability one. Still, I think if things are attractive, simple, and not overwhelming people will learn your interface through experimentation.

Go & Bookmarks

The "Go" menu (not pictured) has some navigational control and then 6 options for different things you can do with Konqueror that have nothing to do with browsing. The ammount of history to be shown in the menu should be lowered from 10 to 5 and removal of the 6 menu entries i mentioned should be considered.
The bookmarks menu is noticeably shorter than the other ones, which tells me either that it can be expanded or that it should be combined with a different menu. "Add Bookmark" and "Bookmark Tabs as folder" can be combined, and "New bookmarks folder" is something that can be done under "Edit Bookmarks" so does not need its own entry.

Settings

In the "Settings" menu lies the embarrasing history of KDE; a record of interfaces that were cluttered with options most of which could either be aggregated or safely removed and never missed. Why are there 5 entries beginning with "Configure"? Shouldn't "Configure Konqueror" contain at least the last 3 within it? KDE has gotten really good at interoperability and in particular implementing things at low levels so that everything that uses their framework gains the benefits. KParts is largely responsible for this, and as far as providing useful features that act similarly across the desktop it truly is second to none in the Linux desktop landscape. But do you really need to configure spell checking options through your web browser?

Throw "Configure Spellchecking" away and combine the rest of them into "Configure Konqueror". "Configure View Profiles" can stay seperate if necessary, but 3 options for view profiles seems a bit much and although I'm not precisely sure how it seems that it can be paired down to 2. The top 3 menu items should all be moved to the "View" menu, because they make no sense in the "Settings" menu.

Help

Finally in the help menu, "Konqueror Handbook" and "Konqueror Introduction" seem too similar to warrant different options; this would also get rid of having 3 separators right next to each other.

comments

+ leave a comment on "KDE 3.4"