We shipped rudimentary support for both HTML/CSS/JS and ECMAScript (QScript) Plasmoids in 4.1. Petri has been working on the HTML based ones and improving that. There is work on a "full" QScript Plasmoid / DataEngine / Runner ScriptEngine set going on in playground, but that work happens in fits and starts at best.

What I'm most concerned about at the moment, however, is the QScript based Plasmoid ScriptEngine currently in kdebase. It's meant to be a minimal approach binding just what is necessary and no more. It currently binds Plasma::DataEngine and provides the basics needed for painting, canvas style.

To take it to where it ought to be bindings for Plasmas::Service, Plasma::Widgets and probably the QGraphicsLayouts are needed. Some additional facilities to load data from the local file system or the network would also be useful.

These facilities can be added one at a time, and given how QScript works they can be done in large part by making sure the proper things are marked as Q_SCRIPTABLE in the Plasma classes. So thankfully making these kinds of "bindings" are far easier and more straightforward than bindings usually are.

The reason this particular ScriptEngine could be rather important is that it comes with no extra dependencies (QScript comes with Qt, after all), quick load times and would enable us to produce a ScriptEngine that is both easily approached (limited API) and easily secured (we can limit what API is available to each Plasmoid at runtime).

If you are interested in helping out with the QScript ScriptEngine, drop me an email. Unlike the MacOS Dashboard work that needed to be done, there are a good number of small targets here that could easily accommodate 3-4 people without problem. Drop me an email if you're interested. (aseigo at kde dot org, in case you don't have it.)

If we can get HTML, ECMAScript and Python together in a good state for 4.2, we will have the ability to offer both flexibility and safety for Plasmoid development. We can start moving people off of C++ in more situations and onto these dynamic languages, both speeding up development time as well as reducing the possibility of crashes.

Simon Edwards committed initial support for writing Plasmoids in Python today. (Pythonoids? Pymoids? hm...) There are some build issues to work out, as it relies on CMake files from kdebindings; those probably need to get moved to kdelibs or some-such.

The support is for the full Plasma API, so essentially anything you can do in C++ you can do in Python. There are a couple of example Python plugins in there, and I hope we can get some tutorials up on Techbase demonstrating how to use the Python bindings.

There's also support for Python DataEngines in there. Huzzah...

I'm looking for someone with a built-from-source KDE 3 around to test this patch to kdebase/kdesktop/minicli.cpp:

- QString Minicli::calculate(const QString &exp)
+ QString Minicli::calculate(const QString &input)
{
QString result, cmd;
+ QString exp = input;
+ //replace commas with dots so european decimals can be calculated
+ exp.replace(QChar(','), ".");

If someone out there could apply it and confirm that it indeed works (symptoms of success would include "100,3*4" coming out as 101.2 401.2), that will make one Pascal d'Hermilly, some guy in Finland and other European-style-command-is-a-decimal-point sorts still using KDE3 happy.

As I don't have a KDE3 codebase kicking around, it's a little inconvenient for me to test this. Any takers? =)

We have a pipeline for Plasma development: if it's an obvious fix/improvement, we commit and rely on post-commit peer review; if it's a manageable patch (no more than a few hundred lines of code) to a core component, we post it on the review board for comment; if it's a huge set of changes, use a branch; if it's a new plugin (plasmoid, runner, dataengine, scriptengine, wallpaper, etc) then start it in playground, move it to kdereview when it's ready and finally to either kdebase or kdeplasma-addons.

Leading up to the 4.0 release when everything was in a mad rush, and then briefly after 4.0 as well, we had an "open trunk/" policy. It was often pretty disastrous and I'd lose whole days to sorting the problems out.

These days patches and plugins alike appear fairly constantly, usually with little or no notice, outside of trunk/. It's a great feature, as it lets people experiment freely without having to worry about destabilizing things or having to get people to validate their ideas before having code to show. It's not uncommon to see a Plasmoid be forked and worked on in the playground with a few fundamental changes to the design of it, sometimes resulting in failure but often in something better than what was started with. The freedom that the playground offers is vital.

(This is not a unique-to-Plasma development style, of course.)

The main challenge for me is keeping up with it all: Right now in kdereview we have two Runners, six Plasmoids, two DataEngines and one ScriptEngine (update: it just got moved to kdebase) under inspection. These should all end up in 4.2.0.

I spent part of today and yesterday going through the Plasmoids in our playground area and have so far come up with six candidates for immediate movement to kdereview, three that should be prioritized for completion (due to the important nature of the feature they provide) and two more that are likely candidates for 4.2 (but aren't there yet). There's another nine that are similarly close and could all be moved to completion with a bit more effort. There are five plasmoids and a handful of scripting examples that will likely form the basis for a set of "How To" examples. There are another 17 I have yet to look at and five that I've just deferred examination on.

And that's just Plasmoids. I still have to take a run through the DataEngines, Runners, ScriptEngines and Wallpapers in playground to complete this round of shooting the development pipeline.

The effort is more than worth it, though, as others have put tons of their time and effort into these additions, and it is these additions which both validate, test and bring user perceivable value to the infrastructure beneath them.

What I do find interesting in going through a lot of these plugins is that when putting finishing touches on things I'm usually removing code and letting the underlying frameworks do more of the work. People tend to create things with a bit more complexity than necessary, and it's fun to watch how as we careful tend to central API like libplasma how the code on the edges shrinks.

When creating a clock, only the code necessary for a clock itself should be present.

I'm really excited about the set of examples, though, as we'll finally have a nice set of simple, clean, clear and self-contained bits of code to demonstrate various techniques in Plasma.

Anyways .. this is a mostly content free blog entry, I know. But whenever I get to poke my head out of the framework code and into the plugins other people are writing I get all giddy. ;)

Working on a set of presentations for a corporate project, Sebastian and I put together some content covering KDE and Plasma topics over the weekend. We thought it would be cool to share some of the results with you. Note that the slides are not designed for use at a conference (too much text and rather brief) but rather as an aide to introducing technical management type people to some of the key concepts.

• Plasma - KDE's Workspace (PDF, 1.1MB)


• Plasma 4.2 overview quicky (AVI, 9 minutes, 17MB)

I should probably upload the screencast to Youtube.com so that people can find it there as well. There is also no cheesy outro music or many highly technical details as my screencasts often have because it was meant for a management meeting. I did manage to throw one or two "inside jokes" in, such as the clock reference, but it's all pretty staid and maybe even a bit boring. Hopefully, however, it's useful.

You can at least get a glance (though at a low framerate due to the screencapture software) at the new applet handles. =)

Lennart Poettering did a pretty good job of going through the various sound APIs on Linux, he even made a diagram. It shows just how varied and complex the soundscape on Linux is.

Unfortunately for his readers, Lennart started riffing in places when he probably should have stuck to the topics he's familiar with. Given that it's me talking here, you can probably guess what the topics included ... yep, Phonon and KNotify.

For Phonon, Lennart said, "Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)" Lennart works with GStreamer, so he will naturally lean towards it, but this statement is incorrect on many levels.

Phonon has only a Qt dependency, so if you are using Qt it's an option; KDE doesn't come into play in that decision. Many of our KDE4 libraries are like that these days actually. Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer.

But what if you only care about Linux? Phonon integrates well with the rest of your Qt code, makes it far simpler to use the underlying engine, and will happily backend onto GStreamer where it exists. But it also allows the user, system administrator or system integrator decide to use something else besides GStreamer. Or, should GStreamer fall out of favour in the future on Linux, you won't have to rewrite your code.

For event notifications, Lennart said, "Use libcanberra, install your sound files according to the XDG Sound Theming/Naming Specifications! (Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.)"

This is the classic "event notifications are about sound" mistake. KNotify is a generic notifications framework that lets you create notifications, in the abstract sense, and then let the framework sort out whether they should be played as sounds, logged to files, etc. Sound is just one aspect of notifications, and providing a centralized mechanism to manage notifications is a (excuse the pun) sound design.

Note also how Lennart used the phrase "Unless your focus is only KDE" twice. What does that actually mean? Honestly: nothing meaningful, though bordering on FUD. That phrase might literally mean (and I'm being gracious here) "If you are use KDE libraries to develop your application." (Yes, it's for Qt-only apps too, as we already know) But what many will probably read it as is this: "If you intend your application to be run only in a KDE desktop ..." That's just wrong ... those frameworks are for use with applications that use Qt and/or KDE libraries. No more, no less and nothing about what one's focus is.

This does bring us back to that blog entry from a few days back about clarifying the KDE brand: in this case it would've made Lennart's characterization of Phonon and Knotify less ambiguous (even if still inaccurate).

Lennart does point out a couple of shortcomings of KNotify: "However it does not support the XDG Sound Theming/Naming Specifications at this point, and also doesn't support caching or passing of event meta-data to an underlying sound system." The sound theme spec thing is a bit lame because it's a brand new spec (GNOME only recently picked it up in their release that was made today) and in typical xdg spec fashion is essentially documentation of one implementation. Others will likely follow, so give it time. The caching bit really has more to do with the sound subsystem, and passing of meta data down into the media layer isn't done either. So I do give him some points there; places we can improve KNotify.

Lennart later says, "Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications." This makes them sound like toys, and while I won't say that Phonon is what you'd want for a high end pro-audio engineering tool, if you look at apps like Amarok2 its pretty obvious that these libraries are rather above the "toy" status.

So when do you want to use Phonon? When you aren't doing high end pro-audio stuff and need to play audio or video (capture will be there soon as well, I see code in the experimental/ folder already) and you want it to work today and tomorrow on Linux, BSD, Solaris, Windows and Mac using the native facilities. Phonon alone may be reason enough to use Qt in your application, in fact, if only just for multimedia features in your application.

When do you want to use KNotify? When you are writing code that uses the KDE libraries and you want to notify the user of something.

To Lennart: you know a lot about audio on Linux. Thanks for your contributions to FOSS and those explanations on your blog of the various audio bits and knobbles in Linuxland. But do everyone a favor and stick to the parts you actually know: you'll look smarter when someone like me doesn't come along and correct you (so you win) and others won't be misled in a blind-leading-the-blind scenario (so your community wins). If you do want to write about Phonon or other Qt/KDE technologies on your blog, I'd be happy to field questions for you as part of your due diligence research.

When KDE people find a problem, they tend to latch onto it like a pitbull with a new chew toy and pound the thing into submission with pragmatic design. Michael's been blogging about global shortcuts, approaching it that oh-so-KDE-fashion. Gotta love it. Since he blogged about making global shortcuts work with apps like Plasma, I figured I'd reply in my blog.

Design-by-blog, the brave new future! Well, we've also talked at length about it on IRC and on mailing lists, too .. so we're not quite in danger of ending up designing KDE by SMS messages yet ;)

Anyways ... Michael suggests the idea of application contexts for shortcuts, and that would be absolutely perfect for Plasma. As software becomes more flexible, more user-maleable (which is different than configurable), I think more and more of our software will end up having to think of things in terms of "contexts".

Mike ran through how Plasma, in the simple case, works right now:

"So let's see what is needed for plasma to work correctly. If an applet is added to an containment register the global shortcut. If you have no id to use create one. QUuid is very helpful in that regard as demonstrated by khotkeys. Associate the id with your applet. Optionally write the current set shortcut to disk after calling setGlobalShortcut() with the id. The shortcut you want is probably not the shortcut you get if the user configured it with the global shortcuts kcm. A choice you currently ignore and change back to whatever you have stored in your configuration."

This isn't quite how it works right now, though. Here's what we do:

• Each widget/applet has a unique ID


• If a shortcut is associated with a widget, we load it from the appletsrc file


• That shortcut gets registered, and right now we just force it (related to current shortcomings that contexts should fix for us)


• If the user changes the configuration, the shortcut action is told about this by the shortcuts kded module


• That shortcut gets written out to the appletsrc for usage in the future


• The shortcut is unregistered (via forgetGlobalShortcut()) when the widget goes away, which can happen when the user removes the widget, swaps layouts or just quits plasma (all three behaviours are quite different)

This isn't perfect, but contexts should resolve our remaining issues nicely and Plasma could then play even nicer with the rest of the desktop session. The remaining question will be when to call forgetGlobalShortcut, and I think the answer is that with contexts in place we'd be able to limit that to widget removal or widget layout exportation.

And yes, this has got to be one my least interesting blog entries in a while. =) Now all of you who read this know what kind of fun and crazy life I lead on the mailing lists. ;)

Pet peeve #47: Assuming that "a KDE app" means "you have to be logged into KDE to use it".

We run into this misconception fairly regularly and it's understandable why from a historical perspective: KDE started out as a "desktop environment project". But come on ... we've only had a fairly clear distinction between desktop and applications for how many years now?

But wait .. it's not clear! Otherwise I wouldn't read stuff like this:

"Amarok sure inspires a lot of KDE-envy for Gnome users. Unfortunately, it doesn’t fit in well in Gnome: It’s written for a different desktop environment, uses a whole different toolkit, and requires a lot of extra libraries to run." - Free Software Magazine, article

The article goes on to pimp Rhythmbox which is all well and good. Use what you want, I say. Make educated decisions and you'll come out further ahead, I also say: If you're suffering from "Amarok envy" and it's the use of KDE libraries that puts you off ... it's time for a re-think.

Let's take the author's complaints one point at a time:

• "It’s written for a different desktop environment": no, it's not. It's written using libraries that come from the KDE project, Qt Software and a handful of other projects. It has nothing to do with a desktop environment, which is something you log into and not an application framework. If Firefox runs on Windows ... is it written for Windows? hmm....


• "uses a whole different toolkit": Sure does, and what's the problem with that? With Qt4, it blends rather seamlessly if you use the Qt4 Gtk theme style. Button order is even swapped on dialogs to fit in with GNOME's idea of proper button order. If you're worried about memory usage, unless you're suffering away on a machine with 256MB of RAM you're worried about all the wrongs things.


• "requires a lot of extra libraries to run": unlike Rhythmbox? *cough* Looking at Amarok's CMakeLists.txt it taps into taglib (very popuplar lib among various players), libgpod (which drags in glib and gdkpixbuf optionally), musicbrainz (Rhythmbox uses this, too), nepomuk, loudmouth, curl, libxml2, openssl ... in other words, stuff you probably already have on your system and of those you might not, are pretty tiny in and of themselves. The only exception to the tiny part would be the Qt and KDE libs, but having those around (and they aren't exactly huge in terms of disk space) opens up a lot of application options to you beyond even just Amarok.

So Amarok fits just fine, and does so on many platforms that are more exotically different from the KDE desktop than GNOME is. So why does this attitude persist?

It's tempting to just say, "Well, the person who wrote that article was obviously not qualified to write such an article." or "People who aren't down with the KDE project will grasp at any straw to make excuses for avoiding applications that run just fine elsewhere." There may even be shades of truth in there, but it's probably not the whole picture. Not only does it ascribe way too much actual intention to the probably honestly mistaken user, it avoids this bit of truth:



That is why marketing and communications exists as a discipline: to share with others in a convincing manner what your strengths are, what your unique points are, what your attributes are .. even what your weaknesses are.

So can we blame anyone but ourselves when people wander about saying and writing silly things like the above? No. Public perception starts with us. This does not mean it's a simple task, one we will always succeed at or one that can be accomplished in a day, a week or even a month. It's often a fairly arduous task that takes application over the long haul, but which in the end can be successful.

In this particular case, I believe we need to stop promoting the KDE desktop as "KDE". Now that we have a really solid application development platform, tons of applications (and application suites) that stand on their own as well as a desktop environment, it's no longer wise to keep the term "KDE" as a shorthand for "that thing you log into that the KDE team writes".

It's too confusing for the consumer, who gets tangled up in the distinction between desktop and applications. (In part, this happens because our integration is so terrific that it's obvious that these apps work well together, to the point that maybe they even require each other!) It gives people like the writer of the aforementioned article an excuse (and perhaps even a valid one) to further spread that confusion.

Quietly, I've been pushing for some changes here and there. At the beginning of this year, we changed the "What is KDE text", as can be seen in press releases and on kde.org: it used to say that KDE was a modern desktop environment, now it says that KDE is an international team that creates Free software. This change in language was not accidental.

Such subtleties are not enough, though. It's obvious and evident given the continued popular misconceptions about the relationship between the KDE workspace and KDE applications that it's not enough.

I've quietly floated a proposal to start using our public communication to make it much more clear where the lines are drawn. In particular, I want to see the KDE workspace marketed under it's own KDE sub-brand. Just as we have "Amarok" or "KOffice" as brands beneath the KDE umbrella (which is not the KDE workspace!), I want to see a brand for the KDE workspace applications so that we can refer to them as something distinct so as to clarify the waters around the meaning of "KDE". This can give us a base on which to build a clear and consistent set of lines around the dev platform (which probably also deserves a brand of its own), the workspace and the applications. They are all "KDE", they all work really well together, share so much technology with each other .. but are also separable and individually valuable pieces. The workspace itself really doesn't deserve to hog the name "KDE" to itself.

While these lines are all pretty obvious to most of us close to KDE, it's painfully obvious it isn't to the world just beyond our own village.

The Marketing Working Group have taken my proposal under consideration and have drafted a somewhat lengthy position proposition out of that proposal. I've been waiting for a bit to see it hit the light of day, though I must confess that every day that passes in which I read another article confusing "KDE" and "the KDE workspace" I grow a little more impatient.

Sometimes when working with oh so serious code, I get distracted by the oh so serious problems (which is all pretty humorous when I step back and consider just what makes it "oh so serious" ... it's rarely something like "feeding the starving children"). The result is that I'll happily work around the little limitations and outright problems in layers below the code I'm working on: my attention is too completely captured by the code at hand.

Which is why I find working with less important code that has obvious solutions to them, such as "toys", to be really useful. I can completely ignore what I'm doing (because it's neither hard nor exactly important) and get a real feel for the code beneath me.

Working on toys that other people have written on top of frameworks I'm at least in part to blame for is even more illuminating because I can see with painful clarity what isn't obvious to people writing stuff on top of my code. With other people's toys, there's little to obscure the design decisions and everything that isn't as simple as it could be is because I have failed in the framework.

So it was the other week when working on the Fifteen Pieces puzzle that I discovered just how non-obvious SVG usage is, how easy it is for people to get wrapped up in complexity that is completely ignorable in QGraphicsView (in this case a handful of methods were removed or consolidated into one small one which was triggered on resize events) and that we really need some simple tool to take a bitmap and turn it into an SVG with labeled IDs. QSvgGenerator is cloooose .. but not quite: it just turns QPainter calls into SVG objects, but doesn't seem to let one actually do things like set object IDs.

Moral of the story: play is an important learning mechanism for many species of animals, and humans are no different. =)

Andreas Pakulat recently blogged about performance issues with KDE 4.1 on his new desktop system. While I agree with some of the comments on that blog entry that his blog would've been better off on the kde-devel or even the kde-core-devel mailing list, since he's uncorked the genie I figured I may as well offer some commentary on the matter for the blogosphere. It's probably useful since it's an issue a lot of people are running into, and it's not fun when you do.

A Line in the Sand

First, I'd like to discuss what constitutes an acceptable experience with KDE 4. There will always be some things, like desktop effects used in KWin, Plasma and KRunner, that simply require a decent video card. However, all of these programs should be runnable without those effects and retain an acceptable user experience even on older (within reason; e.g. not 15 years old ;) hardware. Good news is that they do, given decently supported hardware.

It is not acceptable if KDE 4 feels slower than KDE 3, and it is not acceptable if KDE 4 requires brand new hardware. At the same time, if the drivers for older hardware are simply not up to the task and those drivers aren't updated ... there's not much we can do about it and that hardware, which would otherwise be capable of better things, shouldn't be part of our target. It's also absolutely acceptable if certain features only work if the hardware can support them; this is mostly applicable to features reliant on more advanced graphics techniques.

I've seen the KDE 4 Plasma workspace as well as KDE 4 apps run smoothly on devices as small as the N810, on netbooks like the EEE PC, on older desktops and on new bling-bling laptops. The code base does scale well, but unfortunately it doesn't scale well everywhere ... yet. What gives?

Troubleshooting 101: Note the Variances

Have you ever noticed in these discussions how some people say KDE 4.x is "totally unusably slow" for them while others say the performance is just grand? Others say "it sucks!" and then tweak their graphics system (x.org, driver versions, driver config, kernel modules ...) and say "wow, waaay better!"?

Even if we normalize for differing expectations (one woman's "fast enough" might be another's "unnaceptable), we're still left with variance here even with the same code base. This is a critical observation, because it means that we can search for these variances and then work backwards from them towards possible solutions.

So let's go through a handful of these variances ...

Build Time Optimizations

There are some code paths which are god awful slow in a full debug build of some parts of KDE 4. The code that causes the slowness is great for debugging and troubleshooting, but can suck for performance. It's really hard to do proper "seat of your pants" performance measurements unless we're dealing with debug builds. This has bitten me in the past, and I know it's bitten others as well.

It's one of those occasional and unfortunate trade-offs: a bit of the user experience is diminished by running a full debug build that's better for development.

Measuring Performance

This is also why "seat of your pants" performance measurements are not overly useful. What do I mean by "seat of your pants performance measurements"? Here are some examples: "I ran this program and it just feels slow"; "When I scroll in Konqueror using the arrows keys, scrolling seems really jerky." These observations can be useful as starting points: they let us know what might be actually useful to work on as far as improving the user's experience is.

But to really know what is going on we need to profile the application. Often it's not what you think, and profiling can also let you know when it's debug code that's causing the problem without having to keep a separate release build around. So don't jump to performance conclusions based on "seat of your pants" observations; use them only as clues for where to start.

Valgrind and KCachegrind make profiling stupidly simple and very powerful. Even I can do it. ;)

Areas of Performance

Ok, this is probably stupidly obvious for many people, but there are several parts of the computer that can impact performance negatively.

Main memory (RAM) usage can be one: if main memory fills up for whatever reason (applications using it legitimately, applications leaking, etc) then things tend to fall back to disk swap which is painfully slow; worse, file caching is lost and all file access hits disk, also painfully slow.

CPU over-utilization can also degrade performance (to state the obvoius ;). Unlike memory usage, this usually means one of three things: the application is simply trying to do things that CPU is not capable of (rare these days, outside of truly high end applications); the algorithms used in the application are either buggy or plain inappropriate for the task and should be fixed of changed completely (most likely); there is something happening in software that should be happening in hardware (this is a typical problem with graphics). Again, profile really helps here because it's often next to impossible tell which it is without peering into the runtime execution paths. Sometimes something you think is happening on the graphics hardware isn't because of unexpected behavior in the toolkit or other pieces of software being used, for instance.

GPU under-utilization can degrade painting performance. This is probably one of our biggest weak points right now. Unlike in immersive 3D games which we expect to pin our CPU and/or GPU to 100% to get us the best framerates possible, this is a taboo in productivity applications. But to get a smooth experience without hoggin the CPU, hardware acceleration is required. Doing graphics on the CPU can all too quickly eat up most of the cycles available leaving apps little room to do actual work.

The State of the Art Event Horizon Problem

One of the problems we are facing in KDE 4 right now is that we're trying to deliver a modern user experience. We aren't defining "modern" by "what $OTHER_COMPANY is doing today" but rather by "what matches with our vision of kick ass". There's certainly inspiration and lessons we draw here and there from various companies and other FOSS projects ... but we aren't limiting ourselves to that.

In the process of creating this modern user experience, we are doing things that just haven't been down on the FOSS desktop arena, or in some cases any production user interface arena. This pushes into areas we haven't gone before.

The Plasma performance issues are a great example of that. There have been a number of graphics drivers out there that simply have issues with applications that use translucency (sometimes referred to as "argb visuals"). They work fine with compositing window managers, but that's because they use translucency in a rather different way. x.org itself has/had numerous straight out bugs when it came to argb visuals. I demo'd these issues for various x.org developers and every single one of them I showed it to were surprised about the problems.

Why is this? Well, when Plasma came onto the scene there weren't any other production apps doing to the graphics stack in x.org what Plasma was. Untested code equals unfound bugs and unknown performance boundaries.

Plasma isn't the only area we're running into this kind of "event horizon" issue.

x.org and Graphics, or How I Hope It Won't Do Graphics In the Future

We also deal with things right now like XRender which is supposed to be a way to accelerate certain common rendering activities. Things like text rendering, which is used a lot in applications like web browsers, mail readers, word processors, etc. The probem with XRender is that it is designed in a way that doesn't map all that wonderfully to how graphics hardware tends to work. So while there is decent acceleration for some or most of XRender in some graphics drivers, it's abismal on others and never really reaches the full potential we should be seeing due to design issues.

This isn't the only issue in x.org, but it sort of highlights one of the big ones: x.org has some pretty big issues when it comes to doing graphics. That's why nVidia includes in their driver a rewrite of pretty much every bit of x.org that touches graphics. This in turn causes havoc of a new variety: does nVidia's twinview map nicely to xrandr/xinerama or does it get screwed up? (Answer: often the latter.) Issues that get addressed in x.org need to also be fixed in the nVidia driver if they exist there too, and vice versa. It's just not pretty.

This is one of the primary reasons why I'm very excited about Gallium3D: it's a modern graphic stack done by graphics gurus that is designed for the real world of hardware. I've seen it action, and it's impressive.

If the FOSS desktop world is smart, the future of x.org will be as an application windowing protocol (window management, for instance) and an event system. All hardware support will move into kernel drivers where they belong (this is already happening / happened), and graphics itself will be handled by Gallium3D or something like it.

In the meantime, we're a bit stuck working around and within the limitations of today's x.org reality.

Qt4: Room For Improvement

Qt4 itself has room for improvement. There are graphics paths that do things in software that should be done either smarter in software or in hardware. A proper OpenGL paint engine for Qt4 woudl also rock the house considerably. Note that Qt works very well with OpenGL-in-a-widget, but that's not the same thing. I'm talking about all QPainter operations happening in hardware where available, which is very nearly everywhere these days. Even today's mobile devices can manage this, something driven largely by power usage. We don't have that yet, but when we do things will be nicer.

Before that happens, though, there is still lots of room for improvement in Qt4. I've talked with many of the engineers at Qt Software about these things and they have been working a lot on performance in Qt 4.3 and 4.4 with even more to come in 4.5. Performance is not an easy (or fun) issue, and with all the new code and approaches taken in Qt4 it is taking time to really get it slick-as-snot fast.

This isn't to say that it's slow right now, mind you. It's rather impressive right now given all the features it supports, but it's just not as fast as it could be. Thankfully this is a knwon issue and one that Qt Software people care about enough to actually put substantial and continuous effort into. As these efforts come to fruition, KDE 4 will also "magically" improve in performance.

And Where is KDE's Responsibility In All This?

So I've picked on the whole stack underneath KDE 4 by this point in the blog entry. I don't want to give the false impression, however, that KDE has no culpability in the current situation.

There are few truths to keep in mind that impacts KDE 4's performance:

• For a lot of us, this is the first time we've used these new techniques and we have more to learn about how to use them best.


• There is a lot of very new code in KDE 4, and new code means both new bugs as well as new unoptimized paths.


• We can work around some limitations lower in the stack better than we do now, though sometimes we need to patient and let the stack catch up with us.

Just as with Qt4, and perhaps even more so in places, we have a good amount of optimization work ahead of us. We works for years on optimizing KDE 3 in various ways, and while we carry much of this work with us into KDE 4 we also have huge new sections of code to repeat this effort on.

Bringing the KDE 4 codebase to maturation will help improve performance, and that's something that can only be accomplished over time. Thankfully, we're doing just that. How fast are we doing that? That's something we can only measure in performance deltas between releases.

So ... what does all this mean?!

It means that there is work that needs to be done at every level in the stack. We've taken the FOSS desktop to a whole new level with KDE 4, and we're pushing it even further with each subsequent release. By setting that bar higher than it has been in the past, we've created new areas of work for ourselves.

But because that work is spread out across the stack, it means that there will be vast variance in user experience right now: something as small as a driver revision upgrade can make all the difference in some cases. It also means that we can't just look at the user experience and point a finger at any one thing, e.g. "KDE 4 is slow, so fix it KDE team!" Profiling is critical, so we can pinpoint whether the problem exists in KDE code, Qt code, x.org, drivers .. elsewhere? Then we need to figure out whether it's best to wait for the stack to catch up (and communicate these pain points to the owners of those parts of the stack) or if it is better to change something in KDE's code itself.

Also remember that there are any number of possible issues: text rendering speed, image manipulation performance, graphics in software vs hardware ...

If that sounds like it's not an easy problem, that's because it's not. It's a wicked problem, one with no single cause and no single solution. We need to track down these issues one by one, by profiling code and exercising the software on different hardware/software configurations, and improve them. It will be an incremental process, but it's doable.

It Works For Me

If you think that I'm displaying a lot or maybe even too much confidence, here's why I have that confidence:

Right now, KDE 4 flies on my laptop, and it's hardly a screamer by today's standards. So I know it's possible for KDE 4 to perform very well.

I also keep close tabs on work going on elsewhere in the stack and am very happy with the directionality of it. Work is being done in pretty well all the areas we need work to be done in to improve the event horizon issues.

I wish I could wave a magic wand and make KDE 4 work like a speed demon for everyone, but that's just not realistic right now. At least I know there is light at the end of this tunnel, and that things work well for a large number of people already as it is.

The alternative would be turn around now and go back to a 1990s era desktop as we had in KDE 3. It was solid and stable, but had an extremely limited future for the general user base. Going back to something that has acceptable performance today for everyone but which is a dead end tomorrow isn't really an option, especially when we can get what we have now working as well or better than what we had. We should also avoid rose coloured glasses and remember that performance in KDE 3.0 also sucked with noticeable improvements with each release; the same is happening with KDE 4.

So it's not a perfect world, but one that's getting incrementally better. I doubt that's news to anyone, and I hope that the above helps to at least add some substance to what is often a rather shallow discussion.