KDE Commit-Digest for 20th May 2007

In this week's KDE Commit-Digest: User-visible functionality added in Plasma. Support for animated SVG images in SuperKaramba. Kanagram becomes the latest application to adopt a scalable, SVG-based interface. Initial code imported, as a statement of intention, to support interaction with Exchange servers and the Akonadi PIM data store. Small, incremental improvements in KTorrent. A new round of Coverity fixes, particularly in KOffice and Amarok. Work on loading ODF shapes through Flake in KOffice. KDevelop gets improved support for .ui (user interface layout) files. Branches of KMail, KPPP, Konversation and Kopete created to enable the integration of Solid-based connection management and notification. KDE 3.5.7 is tagged for release early next week.


Any idea where to find it?
I found that with google:

but no code.

By patcito at Mon, 2007/05/21 - 5:00am

The original client called "Knowledge" seems dead to me although this is not reflected on the wikipedia page (

But see
This is the university project that Daniel Molkentin has been involved with.
(The mailing list mentioned there is in German though.)

By cm at Mon, 2007/05/21 - 5:00am

This is a bad thing! I really like it and propose it for all kde apps

By zvonsully at Mon, 2007/05/21 - 5:00am

I love it too - it was a classic "wow" moment when I first encountered it, circa KDE 3.3.
However, the reasoning behind the removal is timer wakeups, which are hefty culprits in processor (and therefore energy) usage, especially on laptops.

A decision therefore needs to be made on the balance of power usage vs. eye candy, saving the planet vs. saving our eyeballs :)

It would be nice for these eye candy features to follow a KDE-wide setting though, one which could be dynamically manipulated by Solid power controls.


By Danny Allen at Mon, 2007/05/21 - 5:00am

Yes, a power safe/feature slide sounds like a good idea to me, uses Solid in a good way I'd think. A KDE to have such power saving feature scheme somewhere? Or is this too vague a feature?

By ac at Mon, 2007/05/21 - 5:00am

This could be an Optional feature that is turned off by default...??

By Emil Sedgh at Mon, 2007/05/21 - 5:00am

> I really like it and propose it for all kde apps

It was an absolutely ghastly hack however, and in its current state it causes Kopete to wake up every 30ms ( that is > 33 times per second ) just to pretend that the scroll bar is being pressed.

That has quite an impact on the power usage of mobile PCs, and even on non-mobile PCs it will have an impact on the performance of other applications.

So unless a proper implementation is forthcoming, it was decided to remove it.

By Robert Knight at Mon, 2007/05/21 - 5:00am

Pity, but I can understand those reasons. I wonder, though, if we will ever see smooth scrolling (not the automatic scroll as in Kopete) in KDE. It's more usable as you can follow content with your eyes, and it looks better as well. Besides a suse hack to have smooth scrolling in Konqi, I haven't seen it much.

Though the Domino style has smooth scrolling on all scrollbars, so it must be possible...

By superstoned at Mon, 2007/05/21 - 5:00am

Personally, smooth scrolling in Konqueror is the one of many thing I disabled. Maybe it's just me, but I feel uncomfortable (giddy) looking at it for a prolonged time.

By me at Mon, 2007/05/21 - 5:00am

Hmm, it was actually one of the things I really loved. Each time I move the mousewheel over the scrollbars it makes me itch, because it still scrolls with fixed steps there.

By Diederik van de... at Mon, 2007/05/21 - 5:00am

Well, I have seen the Domino style for Kde3.5 which implements smooth scrolling for ALL apps. Interestingly, it did not work with Kopete at all where both smooth scrolling implementations produced conflicts (not scrollable at all).

I'd rather like to see the Domino technology (and not only the smooth scrolling feature) in the KDE4 style base class to enable it for all apps....

By Sebastian at Mon, 2007/05/21 - 5:00am

The Kopete smooth scrolling is far better than Dominos.

By Luis at Thu, 2007/05/24 - 5:00am

Yurgh. Couldn't stand it (and quickly disabled it). I'd much rather instantly scroll to where I want to go. Smooth scroll felt floaty and imprecise, and the small amount of time it took to get up to speed and then slow back down to a stop when scrolling irked me to no end.

By jason at Mon, 2007/05/21 - 5:00am

Completely agree. Maybe it would be ok if it was faster or used a more sensible interpolation function, but currently it just makes scrolling more tedious.

By Tim at Tue, 2007/05/22 - 5:00am

Another nod of agreement from this corner. Any small benefit gained from being able to trace the scrolling content with my eyes more easily was negated by the time wasted in waiting for the smooth scrolling to do its thing.

Furthermore, I find the step size is generally small enough for losing track of content to be a non-issue, but I dare say this varies from person to person.

All that said, however, if a proper smooth scrolling implementation came about, and was strictly *optional* (even if it was enabled by default), I don't see how this would be anything but the best of both worlds. Sometimes you *can* please everybody... or almost everybody. :P

By Jeff Parsons at Tue, 2007/05/22 - 5:00am

Personaly, I use a laptop and usualy don't get a moose whith a scrollweel, so this was realy usefull

But I have to agree that when you have the scrollweel, this thing is more anoying than good.

By David at Tue, 2007/05/22 - 5:00am

First of all, congratulations to all plasma developers for the first mentioning in commit-digest ! This may finally calm down all that angry unbelieving trolls ;)

I've taken a look at plasma source and wiki pages and still have one question about plasma design: why this rewriting of standard QT QWidgets is necessarily ? Rewritten copy will deffinitely have less functionality than the original one and will possibly have small differences in behavior that will annoy both programmers and users. Yes, QGraphicsView is really great, but according to several blog posts on the planetkde you still can use QWidgets on it. There is some issues with scaling, but in current implementation plasma widgets are drawn using KStyle which is resolution dependant and still has the same problems with scaling.

Just my thoughts, it'll be great if someone could clarify this here or on the wiki. And again thanks for all your wonderful work !

By Anonymous at Mon, 2007/05/21 - 5:00am

you said you read the blogs about it, probably referring to the ones by andreas at trolltech. if so, they answered your questions. it's not just about resolution independence, but stacking orders, graphical effects and other transformations.

and hopefully we won't need our own copies of these things for long.

> deffinitely have less functionality than the original one

pushbuttons and checkboxes aren't that hard to do. it's not like we're going to be implementing treewidgets and what not.

> and will possibly have small differences in behavior that
> will annoy both programmers and users

given that this isn't meant to be used to write full applications, i highly doubt that. these are simple analogs that are good enough to appear like they belong and fit and are familiar to the user. i doubt most users will even notice and given what applets tend to do, i doubt developers will even care.

it's also temporary; we'll probably be able to replace all this code with qt 4.4 or 4.5, depending on schedules at Trolltech.

By Aaron J. Seigo at Mon, 2007/05/21 - 5:00am

> you said you read the blogs about it, probably referring to the ones by
> andreas at trolltech. if so, they answered your questions

I've just reread Andreas' blogs and yes, now the answer is more clear for me.

> it's also temporary; we'll probably be able to replace all this code with qt
> 4.4 or 4.5, depending on schedules at Trolltech

It's quite good, I'm looking forward to see how Trolltech will solve this !

Thanks a lot for you reply !

And one more question: will the plasma widgets support stylesheets (which can be quite tasty for applets) ?

By Anonymous at Mon, 2007/05/21 - 5:00am

> will the plasma widgets support stylesheets

i'm really not sure at this point. right now they don't, and i'm not sure that's a bad thing. conversely, i'm nearly positive it's not worth the effort for kde 4.0 if we're going to get it for free in qt 4.4 / kde 4.1.

By Aaron Seigo at Tue, 2007/05/22 - 5:00am

Nitpick: The C and C++ mimetype icons look like they say "exit 0;" at the bottom, instead of "return 0;" or "exit(0);"

Am I crazy?

By AC at Mon, 2007/05/21 - 5:00am

It should also say 'int main(......' and being pedantic 'return EXIT_SUCCESS;'

By Anonymous at Mon, 2007/05/21 - 5:00am

return 0 and return EXIT_SUCCESS mean the same thing in C (although I suppose they may signal different "successes", whatever that might mean).

void main, though, is just plain bad.

By KDE User at Mon, 2007/05/21 - 5:00am

yes, but ur observation is accurate none the less

By unknown anonymu... at Mon, 2007/05/21 - 5:00am


Plasma and other module like change radically, but how about KDE Control Center? i never hear that KDE control center will change...., hope the next KDE 4, KDE control center will change radically too..

By Teddy at Mon, 2007/05/21 - 5:00am

given that kcontrol doesn't even work (e.g. list and load control panels) right now, i wouldn't be surprised if exactly that happened.

if it weren't for the horribly 3rd level deep nesting mess that results from our current array of panels, i'd happily suggest system settings at this point. it could use some love and improvement, but it's not a bad place to start =)

By Aaron J. Seigo at Mon, 2007/05/21 - 5:00am

Are there any drafts of what is wanted for KControlCenter or how the new version should look like?

Earlier there were proposals of a KDE registry? Elektra seems to be dead, right?

I really hope we will see some cleanups in the wallpaper field. The Enlightenment project shows how to make a good impressions with high-res visuals.

By Andre at Mon, 2007/05/21 - 5:00am

Please no registry imbecility in KDE. Thank you.

KControlCenter does need to be better organized though. Like getting rid of tabs and instead having more than two levels in the tree on the left. Would be a vast improvement IMHO.

By aha at Mon, 2007/05/21 - 5:00am

Yeash, perfect, a 5 levels nested tree! so to reach your option you have to click-click-click-click-etc-etc

I think that the best approach is the OSX/Kubuntu one, although it needs some cleanup (and some configuration panels could even disappear)

By Davide Ferrari at Mon, 2007/05/21 - 5:00am

Tee Hee!

Invariably the configuration panels missing in Kubuntu are the ones I needed to get to.

apt-get install kcontrol provided the fix.

Please please please don't force me to edit configuration files. It has already happened once in KDE. And not with something trivial. Anyone who thinks googling something a number of times to first find what the developers call the thing, then the way to change it is easier than clicking on a few buttons to get to a nested configuration pane should try it a few times.


By D Kite at Mon, 2007/05/21 - 5:00am

And what are these panels missing in Kubuntu?? Really, I didn't even noticed something was missing (and I'm asking seriously, I'm curious now :)

By Davide Ferrai at Mon, 2007/05/21 - 5:00am

I've noticed. Confused me for ages. I can't remember what they took out but they definitely didn't have all the modules kconfig does (or at least they didn't in the last version).

By Tim at Tue, 2007/05/22 - 5:00am

Agreed. Taking out panels is not the solution. It's just Murphy's law. Other than that, the layout in Kubuntu is rather nice-looking.

What should be more strongly emphasised in both the regular control panel and in the Kubuntu one is search. It already works really well, and could work even better if a conscious effort was done to add more (hidden) key words to the panels.

(Search works less well in the Kubuntu case, because the dimming of icons that don't match the search terms is way too subtle. I have about a 50% chance of guessing whether an icon is dimmed from looking at it, and I don't even have any disabilities. From an accessibility standpoint the search feature is useless in the Kubuntu panel.)

By Martin at Tue, 2007/05/22 - 5:00am

personally I hate the kubuntu thing.
I suppose it is more usable, though, for everyone except me. :)

By Chani at Tue, 2007/05/22 - 5:00am

It's not only you, we are at least two.

I dislike the way it works, but the worst thing by far is the removal of options. Hunting removed settings I know should be there, are beyond annoying.

By Morty at Tue, 2007/05/22 - 5:00am

KRunner in KDE 4 searches through control panel modules pretty nicely. I use it so frequently when I'm writing my KDE 4 articles that I pretty much forget that the Control Centre is borken. Really - I just type 'fonts' into the run dialog, and one of the results is sure to be that config module. Pretty Slick.

By Troy Unrau at Tue, 2007/05/22 - 5:00am

I can't find the option to disable the annoying bouncing cursor for example. :(
(To be honest I haven't really looked for it. I searched for "feedback" once but it returned 0 results)

By Lans at Tue, 2007/05/22 - 5:00am

> Yeash, perfect, a 5 levels nested tree! so to reach your option you have to click-click-click-click-etc-etc

Yes, the exact same number of clicks you make to get to the same screen today, be it two, three, four, or five.

Actually two or three normally. Anything beyond that is for very advanced or expert stuff.

Only the interface is more consistent, and with less clutter, because tabs are visually much messier than nodes of a tree.

But improving the logical grouping, presentation and consistency of all settings is what matters the most. It takes a lot of care and thought.

As always, what is the easiest to use is not the easiest to implement.

By aha at Tue, 2007/05/22 - 5:00am

>the logical grouping, presentation and consistency of all settings is what matters the most

Exactly, if it's two or ten clicks/levels does not matter as long as it's presented in a logical and consistent way. Force all kinds of tricks to minimize levels or number of clicks is just silly, if a increasing the number of levels would give you a more logical interface.

Better to make the most consistent and logical interface possible without imposing such artificial rules. Let the workflow and data decide.

By Morty at Tue, 2007/05/22 - 5:00am

i kind of hope that kcontrol could become a lightweight app with mainly KHTML wiget enabling the editing of system setting though a webinterface (maybe spiced up with some small kparts for stuff that will not fit in a webinterface).

popups should be forbidden.

webinterfaces are more 'scrollable', could easily allow 3rd-party/cross-platform extensions, allows wizard style configuration (like for network connections), a little themeability, etc. etc. etc.

these setting-web-pages would have to be written in a dynamic programming language (ruby, python, KJS). yet they have to hook onto the KDE translation framework.

am i saying something ridiculous? (sorry)


By cies breijs at Tue, 2007/05/22 - 5:00am

Well, it sounds nice, but we currently have a framework for configuration, the config modules (you can invoke a simple config shell with the commandline tool 'kcmshell', try it). So we're only talking about how and where to present these modules, NOT the layout and configuration itself (which depends on the modules).

You can easilly have extensions to this, just introduce a new kcm module.

Themability is KDE-wide, we DON't want applications to theme themselves (have a look at Kopete in this regard, it is, like every KDE app, very flexible, but DOESN't have any useless Kopete-specific skinnable stuff). Of course icons etc are OK.

By superstoned at Tue, 2007/05/22 - 5:00am

regarding themeability i thought more of a kopete-style like theme then a widget-style like theme.

anyway it was just an idea.

By cies breijs at Wed, 2007/05/23 - 5:00am

Marble / Digest quote:

"Don't expect wonders though - you won't be able to spot your house any time soon. However as you might have noticed, that's not Marble's ultimate goal :-) See the FAQ in the docs for more info."

What are you talking about? One day soon KDE will launch their own GPL3 satelites and we will have fully controlled support for this too! ;) Gotta support your KDE Mars users too! KDE universal!

By ac at Mon, 2007/05/21 - 5:00am

first konqi in space? ;)

By Aaron J. Seigo at Mon, 2007/05/21 - 5:00am

Please, please, please... variables or other mechanism to redraw karamba
only when changes happens, i.e.: for amarok music cover image, but also
background images or icons needing to be redrawed too often and also text.

Actually SuperKaramba is using Much more CPU power than kopete smoothscroll.

By mattepiu at Mon, 2007/05/21 - 5:00am

Currently, yes, but that's mostly due to the horrible way it's transparancy works. I'm pretty confident that the KDE 4 plasma way will be much more efficient...

By superstoned at Mon, 2007/05/21 - 5:00am

Transparency in trunk is already a lot better and thus loads of repaints are no longer needed. Which naturally means its a lot smoother and less power hungry.

This also shows a really good reason why it takes longer than the patience of some people in the audience to create this thing. We need to work on general graphics features before its useful to build a beautiful plasma and thus it takes longer before there is something visible.
Plasma just is an appartment flat building that is started 10 stories underground and thus takes a bit of time before it starts to look like something real is happening.

Thanks for the wait! It will be worth it :)

By Thomas Zander at Tue, 2007/05/22 - 5:00am

Redrawing is still a problem with SuperKaramba. Unfortunately the problem is a bit more complex. Redrawing a meter only when the sensor data is changed is a good idea, but unfortunately reading the sensor value takes almost the same amout of time than the drawing. So half of the time of the update process is already wasted with updating sensors.

Authors of system monitor themes tend to refresh the themes quite often, meaning that sensor values will often change, like the cpu load changed from 1 to 2%. And this means that we have to redraw very often.

We also have the problem that some themes force to redraw the widget to dofor animations. Unfortunately the way animations needed to be done in former SK versions doesn't work very well with the QGV, meaning we have to redraw even more in this situation.

On the positive side fake transparency is gone now, so bigger themes should be much faster now. The move to QGV introduced some performance problems but also gives us the opportunity to do some nice eye-candy in the future and perhaps even integration into Plasma.

If you have more comments, wishes or bugs feel free to join us at #superkaramba at

By wirr at Mon, 2007/05/21 - 5:00am

Thanks for that detailed and professional answer.

p.s. SK rocks :)

By Sebastian Sauer at Mon, 2007/05/21 - 5:00am

[i]On the positive side fake transparency is gone now, so bigger themes should be much faster now. The move to QGV introduced some performance problems but also gives us the opportunity to do some nice eye-candy in the future and perhaps even integration into Plasma.[/i]
I thought SK would practically BE Plasma?!? Can you explain the relationship between these two?

By superstoned at Tue, 2007/05/22 - 5:00am