The Road to KDE 4: Updates and Addenda

Well, so far I've published a dozen articles about KDE 4 over the last 12 weeks. A lot of content has been covered, but there is rapid progress still being made on those topics. So, in no particular order, this week's issue deals with addenda and updates to the last 12 articles, so that you can see some of the rapid progress happening as KDE races forward. Read on for details.

First, when I demonstrated KRunner back on January 2nd, it was barely useful, contained temporary artwork (it still does), and looked pretty basic. Since then, it's seen a lot of work. It is now installed by default, sounding the final death of many of the elements that previously belonged to KDesktop, one of KDE's oldest components. It (mostly) works, pops up when you press F2 (see note 1), handles CTRL-ESC to pop up the task manager, handles CTRL-ALT-DEL to pop up the logout dialog, loads the screensaver and screen locking routines as expected, and behaves in a very useful and beautiful fashion. Below is a shot of the new KRunner in action:

There's also this short movie (a week or two old) showing off how KRunner works when searching for commands to run. The interface is not yet final, but it's getting closer to completion. When it is further along, you will certainly get more updates.

Speaking of artwork, during the Oxygen article, I showed off KDE's new logout screen. At the time that was using temporary artwork that was a proof-of-concept placeholder. It's been updated somewhat, and now looks like this:

That's not the only screenshot that needs updating. After the Dolphin article, there were many requests for a tree view in Dolphin. Well, Peter Penz, the lead developer of Dolphin listens to feedback, and within hours, there was a preliminary tree view checked in to KDE SVN. After a few weeks of development, here's what the work-in-progress tree view looks like in Dolphin (this is also a good opportunity to show off some Oxygen icon artwork improvements as well):

And one more shot: back in January, I wrote about some of the work being done on KDE's Job Progress improvements. This section has seen much work since the very initial code I showed off back then, with much of the user feedback to that article helping shape its development. It now has support for pausing downloads, storing a list of finished tasks, searching for keywords among the active tasks (useful if you have 30 tasks on the go), has a simple configuration dialog, and more. The backend that powers this whole system has seen a lot of work, with more discussion with the GNOME folks on standardizing the mechanism so that applications using this progress reporting will run seamlessly on either desktop. Here's a shot of the job monitor and its configuration dialog (see note 2):

okular has received preliminary support for PDF forms, thanks to improvements to the Poppler backend. okular is the first Poppler-based viewer to add support for forms, but more are expected to follow. The implementation isn't particularly useful at the moment, and looks too ugly for screenshots, but the initial support is there. There has been a lot of development happening in okular - which, alongside other KDE developments, you can read about in the weekly KDE Commit-Digest - including support for additional formats, reworked text searching, and more.

Work on Kalzium powers forward: artwork for a student-friendly view is being developed; a better use of the empty space in the center of the table is in place; and work on libavogadro-based 3D molecule viewer is making steady progress.

The rendering in KOffice with regards to text and shape rotation has improved. Part of the problems with the screenshots in my original article is that I was using a bad default font that was shipped by my distribution. Here is a shot of a similar document, but you can see what a difference 2 months can make. In this shot, you'll see a number of new things, including a new 'default text' feature. Where you see the famous 'Lorem ipsum' text, clicking onto the text clears the widget of text, leaving your cursor on a blank text shape. Also shown is content generated automatically using the Kross scripting features, and several Flake shapes also inserted using Kross plugins. The user interface also has seen a lot of improvements, however there is still work to be done: missing icons, font and widgets sizes, and so on.

There were many more changes made to KDE since these articles have gone live, and unfortunately I've only had a change to cover a small handful of them. Of course, for a real look at all the work that's being done, you would need to build the sources yourself on a regular basis. In the meantime, I'll return with more new articles so you don't have to build the sources (though I certainly won't discourage you from doing so!).

1Bug Alert: There is currently a nasty, unsolved bug where KRunner stops responding to ALT-F2 after a period. Fear not, this sort of bug will not be present by the time KDE 4.0 hits the streets, as it would be considered 'show stopper' bug. If, however, you need an excuse to get into KDE 4 development, here's a point of entry that will quickly get you accustomed to KDE and Qt programming.

2Power User Tip: This uiserver screen is usually hidden by default when nothing is happening. If you are running KDE 4, you can make it visible at any time by calling the following command:

qdbus org.kde.uiserver /kuiserver/MainWindow_1


Yes it is. Better to talk about stuff now than when things are set in stone. Reminds me of the Deus Ex 2 dev cycle. There was stuff I didn't like and said so, and people told me to chill, it wasn't done yet. When the demo came out, the same stuff was there and I expressed my dislike and (other) people said "I didn't hear you complain about that (loss of) feature when it was talked about before the demo." Thing is, by then it was too late.

KDE4 is looking more and more like Deus Ex 2, with stuff being cut out and people saying not to knock an alpha. Yeah, like any changes people might like will magically happen before final when development up to this point indicates strongly that they won't. I'm just ignoring Dolphin for now as it just gets me too worked up. I'd rather not ignore KDE4, but I suppose I should do that too.

by Richard Van Den Boom (not verified)

I admire your dedication to calm thigs down. :-D
One thing I'd like to point out : it seems to me that every feature that's in KDE is there because some user at some point requested it and because many users actually like it. That's open source after all.
So when you decide that any type of feature is not right because it's not consistent with a "concept" (OK, I know that no change is planned, I speak in general ;-)), you'll sure to piss off many users.
So it really seems to me that any change that may impact the way people work should be pondered and not really discarded just because of "concepts". There are already a lot of desktops with "concepts" and this usually means you like them or not because you digg in their concepts or not.
I think that a lot of people liked KDE because the whole concept seemed to be : "Do as you like it". So when there is a feeling that a way of working, considered the best for unclear reasons that look more like personal likings than argumented and statically supported choice, is forced down the users, it is not surprising to see uproars.
Of course, many posts are too harsh or make too many asumptions (mine included), but when a real uproar occurs, it should be taken seriously, I think.
Anyway, I still like to thank all the KDE developpers for their involvement in this projet, I'm sure that in the end, the whole thing will be great. I just hope there won't be too much friction in the process.

by Duncan (not verified)

This is one of the few things I've found myself missing from MSWormOS (which as you can tell I don't miss very much!). Not just renaming, but fully working context menus (delete, run, move, rename, specific file-type sensitive actions like extract, etc), both within the file dialog, and within Konqueror itself, when clicking on the directory one is actually /in/ (as opposed to something in it).

Back on MSWormOS, one "power user" trick I used to use /very/ frequently, was popping up the Open/Run dialog, then hitting the browse button, and using what was in effect a mini-file-manager-app. This was faster and easier than opening up a full Explorer (or alternate file manager), just to view or alter some facet of a file or directory (name, attributes, maybe just get a graphical dir listing complete with icons) somewhere, or even move or open/run it, not from the run dialog, but directly from the fully functional context menu directly in the file dialog.

This doesn't seem to work in KDE (3), but I'd sure like it to. =8^)

Similarly, when I right-click on a blank spot in a Konqueror dir listing, I expect to see the context menu for the dir itself, NOT some item that happens to be selected, possibly by default as the first item in the listing, even if it's not even displayed because it is scrolled out of the display window somewhere. If I want the context menu for an item, I will right click on it, using shift and ctrl if necessary to get the menu for a compound selection. If I simply right-click on a blank space in the listing, that's NOT clicking on an icon, but on the displayed directory itself, so that's the context menu I want, NOT the one for some icon that might not even be on screen!

Of course, I'm only using KDE because it's the desktop that already best meets my needs for power and customizability, so these complaints are only in the interest of making the best even better, but I still hope the functionality can make it into KDE 4. =8^)


by Darkelve (not verified)

Just a quick question: is it possible to run a search for files/folders within Open/Save dialogs?

Sort of like Suse has integrated Beagle into Konqueror search field.

by superstoned (not verified)

Yes, at least using KIOslaves. Maybe they will improve the dialog and make it more visible, though.

by Troy Unrau (not verified)

Nepomuk (under a new name, not sure which name will be the final name) and strigi should do this. However, they are not 100% implemented yet. This would be an ideal dialog to take advantage of searching features, especially for the Open dialog.


by Morty (not verified)

If you install the kio-locate IO slave, you can type locate: in all file dialogs. Of course you'll have to install and set up locate, not all distributions do this by default.

by mutlu (not verified)

One click in the Control Center enables Konqueror instead of Dolphin as the default file manager. Not reason to worrry for those who do not like Dolphin the way it is when KDE4 gets released.

by MamiyaOtaru (not verified)

Except that using Konqueror means not getting any of the fixes Dolphin was intended to bring vis a vis having the same app for web and filebrowsing (huge options dialog, mixed bookmarks, unable to have differnet sized toolbars etc etc).

It's like saying "We'll fix that! Don't like the other changes it brings? Don't use the fixed then!" Thanks.

by MamiyaOtaru (not verified)

damnit I told myself I was going to ignore Dolphin. Oh well, as long as I am replying to myself, the line should be "We'll fix that! Don't like the other changes it brings? Don't use the fixes then!" Fixes, not fixed. need edit.

by KDE User (not verified)

My god, thank you for posting this. I pray that the people pushing Dolphin and GTK style file dialogs will have some sense knocked in to them.

by Sutoka (not verified)

Dolphin is NOT a gtk style file dialog. No one is pushing a GTK style file dialog.

Who would have thought a SINGLE widget would get so many people all freaked out (that you can change to the normal line edit!).

by Bill (not verified)

Here are some user interface suggestions:

1) Don't use ellipses (...) to signify overflowing text. Instead, progressively fade the final three characters. This is already implemented in Kicker's taskbar for window titles that are too long (see attached screenshot). It would be nice if the fade-out approach was automatically available on all GUI items whose text might overflow and get cut off: drop down menus, tabs, text fields (URLs, search boxes), tooltips etc.

Fading the last couple of letters is analogous to but more space-efficient than the ellipses (...). Ellipses also have a completely different meaning in a menu item or button label: to tell the user they must provide information before completing their task (see So we should avoid using ellipses to signify shortened words so as not to dilute its original meaning.

2) Dolphin: The Usability Team should take a look at the interaction of the Bookmark panel and the main panel(s) to the right. When I saw "Home" highlighted purple in the bookmark, I expected the contents of the Home Folder to be displayed, instead of Home/dl/temp.

3) In the Progress Manager search field (and for all other text fields, for that matter), there should be a dropdown containing previous searches. The magnifying glass should be a button to the left of the field that users can click. Some users aren't used to the command prompt, so you can't expect them to know that pressing ENTER executes the text -- they expect a clickable button.

4) Progress Manager: Is there really a need for a horizontal separator between the Configure button/Search field and the In Progress/Finished tabs? Same for the vertical separator between Configure button and the Search field.

5) KWord: Given that there is plenty of vertical space on the toolbar, why not make the Bold, Underline, Italic, Strikethrough buttons two-tiered (ie. arranged on top of each other using two rows)? Same for all the other buttons that don't have text captions.

6) Kword: Some of the separators seem redundant, like the one above "Scripts" on the right side. Also, why are there are there two types of separators (dotted and straight-lined)? And why are there fat black bars on the left and right side of KWord's text area?

by TonyB (not verified)

"Also, why are there are there two types of separators (dotted and straight-lined)? " You mean in the toolbar?
The dotted ones indicates a toolbar that can be moved and re-docked or floated elsewhere on the screen( it's like the toolbar's "grippy" handle)
The straight ones are separators between items in the SAME toolbar.

That said, I'm sure there's still some refinement to the number/layout of the toolbars ( and hopefully the usabilty team will get involved, so we'll see some consistency between apps....even if only between the KOffice apps).

As for stacking the toolbars - that may indeed be possible with docking toolbars (can't try it just now )... I don't know if the toolbar button size / text display options can be set on a per-toolbar basis.

by Roderic Morris (not verified)

I agree with your thoughts about ellipses. Not only would that be very useful (ellipses would only be used for menu entries that require more input), but it'd also look very slick.

by Thomas Zander (not verified)

You wrote;
"Ellipses also have a completely different meaning in a menu item or button label: to tell the user they must provide information before completing their task"

Actually; the meaning there is the same as the meaning here. It signifies there is information missing.

by ac (not verified)

but you cannot know _what_ info is "missing"

by zonk (not verified)

The difference is, whether the UI is missing information that you should provide, or if you are missing information that the UI should provide. IMHO it's quite a fundamental difference.

by Tiberiu Ichim (not verified)

The fadout effect was the first thing I've tried to switch off when I started using the new KDEs, and the only thing I couldn't achieve. I feel that it stresses my eyes, as I'm struggling to read the fade out text. Wouldn't it be possible to have this effect configurable?

by Vlad (not verified)

> I'm struggling to read the fade out text.

Actually the fade out effect lets you see more text than the ellipses do. With ellipses, the last three letters are completely replaced with three dots, which are not very informative. I'd rather have three slighly faded letters than no letters at all.

> Wouldn't it be possible to have this effect configurable?

Yup, I agree that it should be configurable.

by Matt (not verified)

I would be very interested to hear what options are currently on the table for point 5. The mix of text under icon and icon only for toolbars is very bad aesthetically and from a space efficiency point of view. I've not seen any changes to improve this layout since KDE4 screenshots started coming out, so I'm wondering if anything is planned yet?

I like the idea of toolbars of different heights existing simultaneously, this is not possible with KDE3. You could save a lot of space by stacking 2 thin toolbars alongside a thick one.

Of course I would turn off the text under icons anyway ;) If I had to have text then text to the right is a lot better and saves more space in my opinion. Gwenview defaults to a mix of these two styles quite nicely with the text only on the less obvious icons.

by Debian User (not verified)

Compliment for your well done comments. I esp. like the fading stuff. Now that you said I noticed that my Kicker does it. It's really very intuitive in meaning. That's great usability.

Yours, Kay

by StormReaver (not verified)

I truly hope fading of text is NOT used (or an option is provided to revert to ellipsis). The fading text on the task bar makes it look like my monitor is smudged in multiple places.

by Christopher (not verified)

>> 2) Dolphin: The Usability Team should take a look at the interaction of the
>> Bookmark panel and the main panel(s) to the right. When I saw "Home"
>> highlighted purple in the bookmark, I expected the contents of the Home Folder
>> to be displayed, instead of Home/dl/temp.

What about the overall placement of the bookmarks? They seem to be wasting quite a bit of space in their own panel; why not move them up in to the main taskbar next to the view change options, or in with the information tab like in Windows Explorer?

by Andy (not verified)

Browser sidebars are ugly usability wise

Bookmarks should be in the main window or tab, same goes for history

by reihal (not verified)

The icons shown in Dolphin are just bad. They dont't workat all in that small size.

That dog-eared paper symbol for files other than text based documents is just wrong. At least remove the paper symbol for the multimedia type files. Where is Everaldo? (And Mosfet?)

by Troy Unrau (not verified)

Mosfet never drew icons - he did widget themes and so forth, in the KDE 2.x series. Coding, not drawing. He had gotten married and moved on, as far as I know. I don't know about Everaldo, but the crystal icon set has not been updated in a long time. (It still lives in KDE 4 in the kde-artwork module for those who prefer it... Actually, the hi-color icon theme is still there from KDE 2.x as well, if anyone cares :P )

KDE has a constant but slow turnover of developers, artists, translators, and so forth. The biggest causes being university graduation; marriage/children; and new jobs with high time commitments. Uni graduation is the worst though, as many of our most prolific coders are also students. Unless they get jobs at Trolltech, graduation usually seriously hinders their KDE time. I myself may fall prey to that one within the next while :)

Anyway, you can resize the icons to fit your needs. In the Dolphin config dialog, there's a slider for icon size... the icons are SVG, so they look decent at just about any size you'd like, except perhaps really small sizes :) Still a work in progress though folks :)

by Beavis Christ (not verified)

I agree. The icons in these screenshots look positively horrid. They're much too detailed for a small icon size.

by Henry S. (not verified)

I think they look fine at this stage. I like the photo-realistic
direction it is going. Perhaps there will be further improvements
as we approach KDE 4.0 that may please more folks. As a programmer,
I don't like to be overly critical of works-in-progress.

by superstoned (not verified)

Indeed, I like'em too, and they're still working on them. What I don't like, though, is the shadow: it sometimes looks really silly and out-of-place. Check the dolphin screenshot, where there is a shadow beneath the little button which can turn the breadcrump into a lineedit... Looks really weird.

by pinheiro (not verified)

Not intirly oxygen foult there, kde tends to miss use icons were they are not suposed to be, like action icons as mimetype icons and so on. This is beeing worked out.

by eMPee (not verified)

first of all, glad the code is coming along and we'll finally have the desktop revolution by late autumn, thanks for anyone contributing to this great project.
I have some issues with the present state as shown in the screenshots here, one of them, yes, being the icon set. Current Oxygen icons
- do have too little contrast around the *border*. There is some sort of shadow thing in the SVG files, which would have to be increased quite a bit to make the icons easily recognizable using light window styles. Crystal is great not only because it has colorful icons with a nice color palette but _great contrast_ of the icons (mostly)..
- the folder icon looks mashed up in the tree. The KDE3 one is much much better, have a look and see for yourself someone.
- the view angles are problematic for me. Some icons (printer, scanner,...) need more 3d imho (=> tilt them a bit?), some less (folder icon..). That is of course only my highly subjective point of view.
- The screenshot of the progress manager shows one most ugly thing: the 'file://' in front of local paths. That is WAY bad. Please make it go away everywhere by default. We never needed it the decades before and it is not a feature. Them escaped sequences (%20) look not good too.
- Considering microtypographic standards, text kerning in Koffice is just not good enough right now. Perhaps the output of LaTeX would be a good reference target to aim for, kinda.

Except from the last, those are all minor things though and I know they'll be fixed when stuff gets on air. Thx for that already ;)

by Manabu (not verified)

Agree with all! That is why everyone is talking about the icons being washed out.

by MamiyaOtaru (not verified)

The kerning is indeed as awful as it always was. The standard response was always "it will be fixed with Qt4." Is the answer actually "never" then?

by Manabu (not verified)

The icons sizes are more sane this time. I don't like big icons, and they are realy unusable in 800x600 screens. Remember: these screns are 10% of all computers surfing the web, and probably more if you count the ones not connected. I was in one of those some time ago, and Windows 2000, and even Windos XP desktops were much more usable than KDE and especialy Gnome. I hope it at least don't get worse in KDE4.

by David Vignoni (not verified)


So I see many comments here that means nothing to me. Really.

have you tryied the theme or you are just guessing that the icons shown there won't resize well?
FYI there are small version of almost every icon.
Everaldo is here:

the size shown there is 32x32. Dolphin is loading an action icon called folder.svg instead of the real folder in "places" directory.

by reihal (not verified)

Everaldo is here too:

Everybody and his dog supports Crystal SVG icons, except the KDE developers.
It's a mystery.

by Luca Beltrame (not verified)

For a while Crystal did not have a license at all. Secondly, there were problems in getting the sources for the icons.
I fully support the switch from Crystal to Oxygen (which I like better anyway).

by Darkelve (not verified)

Thanks for another great article.

And I must say... I love the job progress thingy

by misiaczkowski (not verified)

Please I hate grey could you... i don't know mix it with white?

by zonk (not verified)

UI colors are configurable in the Control Center. Don't like it - use a different color scheme.

Pozdrawiam :)

by Basic user (not verified)

Please don't waste your time with dolphin!
Don't waste your time with win$32, win$16, win$47!
Don't waste your time with "new" icons!
Don't waste your time with "better" interface for kcontrol!

We enjoy ad want your wonderful work!!

by Troy Unrau (not verified)

You have a lot to learn about how KDE and open source communities work.

Programmers work on whatever they feel like working on: in this case, Dolphin. Artists work on artwork, but they work on what they feel like working on: in this case, icons. You cannot simply assign them to another task - KDE is not a corporation with a bottom line and managers and so forth.

So not a single developer is wasting their time, as they are working on what they prefer to work on. If they weren't, they'd be doing nothing. And given the choice between the two of them...

by Henry Miller (not verified)

There is a lot of work that MUST be done before kde4 can be released. While there is some talk that maybe kde 4.1 libraries won't be binary compatible with 4.0, everyone agrees we don't want to. (but we may discover some things that need to be redone after 4.0)

There is still a lot of known library work that must be done. The people doing that work are not the people working on things like dolphin, win32, mac, icons, or userinterface. Too many chefs in the library code would spoil the broth, and anyway most developers are not ready for library work (which is harder than regular development). That isn't saying we don't need more people working on the library, we do - but the people working on the "other" stuff are not necessarily the people who would be good in the library. Icon work is something for artists, not developers - both skills rarely exist in the same person.

Also, library development requires that everything be used. Dolphin (and other things that can change latter) gets help from library developers, because the library developers do something that seems interesting and they want to see it work. When you write a new library interface useful for eye candy, you want to see it, so you stop the library work for a bit to make some application use that eye candy.

Last, most developers are not paid for any particular work. So if they want to do something that isn't important for kde4, we can't make them.

by David Vignoni (not verified)

That's trolling.

by reihal (not verified)

No, it's paranoia.
Fear of abandonment.

by Mogger (not verified)


It is wonderful to see the result of everyone's hard work. Thanks for the interesting reading Troy.
It's great to see that you actually can contribute and affect, even if you don’t know programming or have the title "usability expert". I am just a normal user, but here are some of my suggestions:

1. Eye candy for logout screen

I like the updated logout screen. However, I think it would look even nicer with some small changes:
a) White (transparent) border instead of the current gray and
b) a shadow.
Here is the result:
The left one is the "current" one, and to the right you can see my proposal.
I think the dots to indicate the focused button look out of place, but I guess it has lower priority and (hopefully) will be fixed later.

2. Krunner "alt+F2" interface

I like the mockup of Leo Spalteholz on KDE-look. You can find it here:

Why? Because it feels less "cluttered", and you see directly what the commands do.
I have made a new mockup, based on Leo's. Please note two things: I haven't included the buttons, and the fonts look horribly.
This way, with the information divided into two lines, I think you get a better overview. Again, please ignore the ugly fonts.
A Horizontal scrollbar should in my opinion be avoided and (almost) any cost.

And I wonder if the text "Enter the name of an application ---" [let's call this the help text] really is necessary? If it is, a solution could be to show this text in the "result" list below the text field, if the user hasn’t typed anything in the text field.
The problem is what's shown in the list by default, when the text field is empty? I think showing the last 5 used commands [now called history] or something similar would make sense.
If that's the case, maybe you could shown [help text] by default, and if the user presses the up/down arrow keys on the keyboard, then show [history]. If s/he starts typing, show the result as always.

I also think that the Launch and Cancel should look like buttons.

3. Process Manager

I hope the interface gets some love (too much information / takes too much space right now in my opinion), but it's really good to see the improvements!
And a comment to Bills' suggestion,
>> The magnifying glass should be a button to the left of the field that users can click. Some users aren't used to the command prompt, so you can't expect them to know that pressing ENTER executes the text -- they expect a clickable button.
I don't know if it's a search field of filter field, but it’s probably the latter. Then it filters as you type, no need for a button.

4. The :::: Toolbars ::::

Sorry, I don't know what to call them. But they appear in e.g. Dolphin’s "Bookmarks" panel, "Folders" etc.
First, I really dislike the dots. I know they indicate that they are movable, and that it depends on the style you're using.
And what does the "Restore" button do? If it just undocks the panel, then I see no reason for it - you can as well just drag it, can't you?
I like Adobe's solution, for example in Premiere:
They appear as tab-like things, and you can group panels if you want. I don't know if the grouping is necessary, but it could be useful in for example KOfice, I think.
Not quite possible to see this in KDE4 though. However, can’t you make the drag able space smaller, for example have the text left aligned and the dots just to the left of the text?
:: Example [x]

5. Some side notes
a) The folder icons look like they are floating - maybe remove the shadow underneath?
b) Bill (again) wrote about ellipses. I like the fade effect, but it's sad that it distracts some people.

Finally, I just want to say: thanks for reading this, and keep on with the great work!

by Troy Unrau (not verified)

Thanks for all the constructive feedback :)

1) The logout screen is composited on the fly based on a background SVG and some button SVG's - so it's a really simple change to make. What I suggest is that you grab the SVG's in question, and play with them. I'm sure the artists would appreciate any improvements.

That said, the button SVG's got updated a few hours after I took my screenshot. Not sure how the new one looks, side-by-side...

2) The KRunner interface is still seeing a lot of work, and what the still shows is not the whole interface. The list is going to be replaced (eventually) by something better :) The mockup looks nice though: maybe you should pop into #plasma on and make sure that they see it :)

3) It is indeed a filter field...

4) I think the dots and so forth that you are seeing in my screenshot are a very work-in-progress sort of appearance. Grouping is available in KDE 4 as well, and it'll automatically degenerate into tabs. So this then becomes a matter of style. The default style will be changed before KDE 4.0 launches...

There's still much work happening on this widget, and I notice changes happening on a week-to-week basis.

by Mogger (not verified)

Thank you for your response. I know that these are all work in process, just thought it is better to point something out early, than complaining when the work's almost finished. :)

About Krunner, I read about some "icon parade" that is going to replace the list view. However, when I read "The interface is not yet final, but it's getting closer to completion.", I thought that this view will be the one featured in KDE4.

I would like to help with the development, however, I simply haven't got enough time. The series "The road to KDE 4" is really great, now I can follow (at least a part of) the development without compiling and hacking stuff.

by Johann Ollivier... (not verified)

thanks for these comment !

For the 1), i think what you did is better than mine. I'll update soon. thanks.