I've been running KDE4 desktop since May and I've constantly suffered from poor desktop performance and various graphics card related problems. Now I've solved those problems: I've bought an ATI card. Despite NVidia releasing the new Linux driver and suggesting to tweak several performance-related configuration options, I still decided to go and spend $50 on the new video card. Here is the long story why...

On my NVidia GT8600 KDE4 had several types of performance problems:

1. Slow repainting of windows

When I used KWin as a window manager with disabled compositing (sic!), main windows of KDE4 applications took too much time to repaint themselves upon switching. When I used other window manager (twm for instance :)), the repainting was a lot faster. Measurements showed that KWin suddenly took more than 40% of CPU on window switching. Turning on compositing (aka "desktop effects") greatly improved KWin performance, but compositing was a no-go for me for the reasons I'll explain below.

Status of the problem: could not be solved for me.

2. Slow resizing of windows and plasma applets

That's the problem all people using NVidia cards saw. It was the most severe but NVidia forum's suggestions helped.

I created an autostart script

#!/bin/bash
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

and added 3 more configuration options to the xorg.conf:

Option "PixmapCacheSize" "3000000"
Option "AllowSHMPixmaps" "0"
Option "OnDemandVBlankInterrupts" "True"

This all helped to get reasonable performance. Some people report that for them KDE4 flies with such configuration. For me it did not fly. The performance was just bearable, but KDE3 desktop was simply a lot faster.

Status of the problem: almost solved.

3. Slow desktop effects

KDE4 with desktop effects turned on, remind me of running a heavy video game on integrated graphics card :) Slowness, freezes and so on.

Using the newest driver and all options I told about above solved the problem. Once again, almost solved. Virtual desktop switching effects would still freeze times to times.

In any case, I didn't care much because every time I turned on compositing, scrolling speed in Firefox degraded by an order of magnitude. I have to use Firefox a lot these days because I do web development at work so compositing became a complete "no-go" for me. Therefore I didn't really cared much about it being slow. I could be happy if only KWin hadn't got the problems with slow window repainting (the problem #1).

Status of the problem: almost solved.

4. Slow painting in KDE4 apps

This problem didn't depend on window manager or compositing. It was always visible and the most annoying. It was also quite hard to track down and profile.

One example was a listview widget in akregator with a list of posts. I have hundreds of posts there and listview scrolling was too slow for me. Valgrind said that the text painting was a problem. My laptop with old ATI X1600 card (and open-source driver) rendered the same text a lot faster and scrolling in akregator wasn't an issue at all.

Second example was kate also having problems with painting text (see bug report for details). The painting algorithm in kate part may not be ideal, but my system was supposed to be fast enough to counterbalance that. In reality, painting text with the nvidia driver was just too slow and non-optimal algorithm just merely increased the annoyance.

Status of the problem: I was unable to solve it.

5. Corruption of system tray icons

Almost always icons in system tray were rendered with some weird background consisting from parts of other system tray icons. No driver updates and config options solved this problem

Status of the problem: I was unable to solve it.

Conclusion

After several months of self-torturing I decided that it was enough for me. I went to the local shop and got a cheap ATI Radeon 3450 card for $50. It's inferior to my 8600GT but I don't care much because KDE4 just flies on it. And by "flies" I do mean that it's really really fast. All 5 problems I've listed above are gone now. Period. Finita la comedia :)

It's not like things are all that shiny with an ATI. I miss the brightness setting in the driver (with nvidia you could do something like nvidia-settings -a Brightness=-0.4) and Firefox is still slow with compositing enabled. But in any case my desktop doesn't bother me anymore and I can just enjoy using it.

Update:
If after reading this post you think of selling your NVidia card and buying ATI, please note that proprietary ATI driver has at this moment (October 2008) several problems I know and can confirm:

• video (xv and gl) doesn't work with composite turned on - it flickers


• Xorg may fail to properly shutdown leaving only blank black screen


• scrolling is still slow in Firefox with compositing turned on

For me desktop effects are not important at all, I turn them off. Be aware of the problems listed above if you intend to use X composite extension and desktop effects in KDE4.

Tomorrow most people will be back from the holiday season, time to start again with the biweekly IRC meetings of the openSUSE KDE Team. This time we will look back to last year or rather to the openSUSE 11.1 release shortly before Christmas and the biggest reported problems. And also, despite the schedule discussion not being finished yet, we will start to collect and discuss ideas for openSUSE 11.2.

Do you think that you have significant amount of experience to work as a mentor at KDE forums? Then you should consider joining the team! Read on…

What do mentors do?
Mentors are responsible for conducting Klassroom sessions. For those who aren’t familiar with the KDE Forum klassroom concept, read this post.
You will be conducting a “Kourse” (lesson) at the Klassroom area. The lesson can be something like “Fixing XYZ bugs” or “Documentation kourse for project ABC”. You will guide a team of “students” (who will apply for your kourse beforehand). Your motive will not only be to contribute to KDE but help them learn how to do so.

Why are mentors needed?
With the great success of the klassroom concept, we are looking forward to have more sessions (at higher frequency). For that, we would need more contributors who can undertake and organize sessions. Existing mentors are listed here.

What all would you have to do?
After joining the mentors group, you will have access to the mentor team forums and moderational access to the Klassroom forum. You can start by posting a draft of the kourse you will be conducting, which can be reviewed by other mentors and forum staff. Once ready for shipping, your draft will be announced for public viewing and you can start with the kourse at the Active Kourses area. Your kourse can be based on any of the following:

• Bug fixing and development in general
• Documentation and screencasts
• Any form of KDE artwork
• Translations

At present, you would be handling a small team of 5-6 students, though this limit may go up depending upon the interested candidates and kourse popularity. After joining, you can also optionally have a “Mentor” badge for your username.

How can I apply?
If you are interested to contribute, you can send a PM to neverendingo (requires registration on the forums) or find him on IRC: channel #kde-forum, network freenode.
In case you send a PM, don’t forget to include a short introduction of yourself and your plans (if any) for upcoming kourses.

I work with bugs.kde.org nearly every single day.

Most people who report bugs on it hardly ever visit it, and that's not a bad thing.

Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.

Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.

Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:

• Always include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect.


• If reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps in detail needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems.


• If you are reporting a crash, always include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even more important. However, first consider reading this how-to on creating nice backtraces and get a realy good backtrace for the report.


• Do not upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments.


• If the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question.


• If the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that.


• If you can't reproduce the bug after a while, let us know. That's useful information.


• If we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there.


• Do not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File new reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones.


• Which leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic. ;)


• Whenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... even if the report is closed. So feel free to add comments to reports, someone somewhere will still get a notice of them.


• Fixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer.


• Describe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them.


• You don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't have to come up with a solution.


• I hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report.


• Don't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)


• Don't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. ;) In general, I put far more weight behind how many duplicates a report has than votes.


• When it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything.


• Saying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps.

Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)

Earlier today Dirk sent a message to the release team and KDE core devel mailing lists noting that KDE 4.2 is now branched off of mainline and that the the first RC is being tagged. That means trunk is now what 4.3 will be.

As I've been reminded a few times already today myself, that means we need to backport bugfixes made to trunk that we want to appear in 4.2. The svnbackport script in kdesdk was updated today to backport to the new 4.2 branch and makes the process of backporting your last commit trivial.

The last few weeks leading up to a release are always exciting and nerve wracking for me. There are numerous details that always need to be worked out, though the project is getting better and not leaving things to the last minute. The promo team has been working on release materials since sometime in December, even. Hopefully that reduces the stress levels and burn out rates. =)

In a couple week's time it'll be full throttle on 4.3 ..

Let us start with a screenshot:

The graph itself is not something new, since I just recreated SquirrelFish Extreme comparison (against its predecessors). The focus is actually the tool which was used to generate that bar chart.

For the code and a little explanation, check out what I wrote on Qt Labs on the topic of QtScript-based bar chart.

Over on planet.gnome.org, Ted Gould blogs about how the current system tray protocol sucks. I've written about the systray recently, but I started writing about how much it sucks 5 years ago. I wrote about it in a number of places, and sent mails to the xdg list.

Of course, I was always busy with one more thing and nobody else really seemed to care. In fact, some told me I was being silly and the current system was just fine. I wonder if those people even remember. =)

In any case, it seems like hell is finally freezing over: we have a system tray widget in 4.2 that is built for multiple backends (and already has a couple) so that we can freely mix and match old with new as a realistic path forward, and people in other projects are talking about doing actual work in the same area too.

Hopefully Ted isn't going to make the same mistake I did, which is to realize the error of our ways then not actually do anything about it for a couple years because there are so many other pressing things to do. ;)

I also hope that in their thinking about these things that as they move to implementation that they keep us (the F/OSS desktop world) information and even share their plans as they go forward. I personally plan on sending something to freedesktop.org once we have something we can show works reasonably.

Yes indeed ... I think the Devil be shaking, and it ain't out of fear.

Hi KDE people that are coming to FOSDEM,


Here are some small adaptations to the hotel reservation.

In the meanwhile I managed to get an option untill 19 januari for Hotel Albert.


For those still in search of a nice hotel, I managed to get a reduction on rooms in a very nice hotel in the center of Brussels. Very positive: the hotel has free wi-fi!

If you make your reservations at this hotel, please do not forget to mention "KDE voor Emile" to obtain these special prices.

Prices for KDE are:
single room 45 EUR
double/twin room 50 EUR
Tripple room 60 EUR
Quadouble room 70 EUR

Breakfast is included in these price.


You can make your reservations by calling the hotel, by e-mail or by means of the reservation form online.

It is a very nice hotel with 2 up to 3 stars.

Since I do not have an option on these rooms, it will be first reservation = first gets. Rooms are limited, there this hotel is situated very central and very popular with tourists.

Hotel information:
Albert

Koninklijke Sint Mariastraat,27
+32.2.217 93 91
info@hotelalbert.be
www.hotelalbert.be

Situated:
Hotel Albert is situated very near Brussels "Kruidentuin or Botanique" (Herb Garden). Acros the streat you'll find a concerts hall "Hallen van Schaarbeek", where in the weekends concerts and cultural events are kept. The hotel is almost next to Nord Station, very near the shopping area, the central station and the Royal Palace. Every room has a shower, toilet, flat screen television, hair dryer, FREE WIFI.
Bus 272 stops in front of the hotel and goes directly to Brussels airport. For other transportation, Brussels Nord station is almost next door.



An other option:
It is also possible to book in the hotel where KDE stayed last year. It is situated a little less central, but still has a good connection to public transport.
Prices are more or less in the same rate. http://www.hotelsabina.be/
Also here make sure to use "KDE" in your reservation!

After 2008's Tokamak in Italy, I blogged about scripting and my cracktastic thoughts on it. I mumbled on about ninjas and myspacers and apparently the drugs are still in my system because I still think it's a solid approach to the problem.

Thankfully I was able to convince a couple others of that as well and the widgets API we put into libplasma, which really just wrap plain QWidgets-in-QGraphicsProxyWidgets thereby taking the boredom out of using them and giving a nice scripting-friendly view on them, was one result. The other was the JavaScript AppletScriptEngine in kdebase.

Rich Moore started the work on these and got a fair ways into it. Then he got busy with his day job. Then he got really busy with his day job. We talked about it on IRC a bit, and I said I'd try to help pick up the slack. Chani and I ended up doing the widget API and Rich got some more work done on the script engine. Then Rich got really, really busy and things stagnated. It happens. (Rich, if you're reading this, we can't wait to see back around. =)

Then Chani decided the other week to write a Plasmoid. Something simple. After months of work on the widgets-on-screensaver insanity project I totally understood her desire for something a little less frustrating, a little more immediate and lot more fun.

However, I begin to think that "Chani" means "trickster" in some devious ancient language because she started doing it in JavaScript. Not with the "ninja" engine in playground (sensible, it's still in playground after all) but with the "myspacer" one that had already trundled into kdebase. That was when we got reminded how incomplete it was.

So Chani, Marco and I jumped on the poor beast and over the span of a few days implemented access to DataEngines, Services, context menu actions, configuration settings, layouts, access images shipped with the Plasmoid in its package and more. The foundation we built on (Qt, QScript, the core KDE libs, libplasma and Rich's initial work in the engine) were all solid and so we raced ahead at great pace and now you can do actually useful things with it.

We wrote a few little test applets to poke at the engine with and as tagging approaches within the next 24 hours for RC1 it's actually moderately useful. =) Take this guy for example:

If we remove the debug output and whitespace, it's 27 lines of JavaScript that can control any music player that exports an MPRIS controller interface (thanks to the nowplaying DataEngine). It all starts with:

engine = dataEngine("nowplaying");
watchingPlayer =  engine.sources[0];
controller = service("nowplaying", watchingPlayer);

Yep, it just rips right into things, grabbing DataEngines and Services and flinging them around. In C++ we would've written a couple dozen lines of code (class declaration, constructors, etc, etc) and a CMakeLists.txt to get this far. So while the Plasma, KDE and Qt APIs are great, there's entry overhead we can avoid by using higher level langauges in the right places, no doubt about that.

Next it defines three functions: dataUpdate, stop and setProgress. I won't bore you with those, you can see them yourself over on websvn by looking at the whole file. It then makes a simple UI, all sparkly, performant and themed thanks to libplasma and Qt:

layout = new LinearLayout(plasmoid);
layout.setOrientation(QtVertical);

label = new Label();
layout.addItem(label);

stop = new PushButton();
stop.text = "Stop";
layout.addItem(stop);

progress = new Slider();
progress.orientation = QtHorizontal;
layout.addItem(progress);

It then glues stuff together:

stop.clicked.connect(plasmoid.stop);
progress.sliderMoved.connect(plasmoid.setProgress);

controller.associateWidget(stop, "stop");
controller.associateWidget(progress, "progress");

engine.connectSource(watchingPlayer, plasmoid, 500);

Those controller lines are somewhat magical. They connect the widget to aspects of the Service, so when for instance the music stops the Stop button automatically fades out and becomes disabled. Neat.

The last line connects the DataEngine up and the widget "goes live" at that point. When the music player starts playing, the Stop button becomes enabled, the name of the song, artist and time is printed in the label above and the progress slider starts marching along.

Clicking Stop actually stops the player as you'd expect:

plasmoid.stop = function()
{
    controller.startOperationCall(controller.operationDescription("stop"));
}

Moving the slider seeks within the song:

plasmoid.setProgress = function(progress)
{
    operation = controller.operationDescription("seek");
    operation.seconds = progress;
    controller.startOperationCall(operation);
}

All pretty simple stuff, and documentation for the entire API exposed in this simplified window into Plasma is on the way.

Installing the Plasmoid itself is a snap: plasmapkg -i script-nowplaying. In it's final form as a zip file (so `zip -r nowplaying.plasmoid *` in the root dir of the plasmoid), `plasmapkg -i nowplaying.plasmoid` suffices or you can install it via the Add Widgets dialog in the Plasma desktop shell. The Plasmoid above becomes a 1.5K file on disk that you can toss about quite easily, including between operating systems with completely different toolchains and hardware architectures.

We have planned out some tools to help you create Plasmoids extremely easily, so there will be no need to know the packaging details at all for instance. These things will only get better.

I'm really impressed with how quickly it came together over the last few days compared to how actually useful it already is. Writing a high quality language runtime is not an easy task. Writing frameworks like Qt, KDE's core libs, Solid, Phonon, Plasma, etc are also not easy tasks. But gluing the results of those two efforts together? Amazingly quick, if a little black magic-y in places.

Thanks go out to everyone whose worked on those hard bits, and especially Rich Moore, Marco and Chani for helping bring this part of the puzzle together.

Where Do We Go From Here?

If you care about non-C++ languages and Plasma, come join us. We've already got a few Ruboids and Pythonistas hanging about on plasma-devel@kde.org and on #plasma writing Plasmoids, but we need more of you. JavaScripters with an itch to scratch should come join us, too. We need to kick the living crap out of these ScriptEngines and torture them in all sorts of ways, just as we have the C++ libplasma over the last year, and create cool things with them in the process. This way we can go from our first-cut ScriptEngines in 4.2 here to kick ass ones in 4.3.

We're willing, in fact desiring, to improve, modify and grow the ScriptEngines in response to usage. It's the best (some might say only) way, really. =)

I'll be announcing the documentation for the Basic JavaScript ScriptEngine when it's ready to go so you can all jump on it. The docs will come pre-4.2.0, so that you should be able to upgrade to KDE 4.2 and start hacking JavaScript with documentation in hand all in the same day without compiling any C++ on your own. Huzzah.

Networkmanager is a daemon that keeps track of lower level bits on computers that have changing network hardware. It's designed to do this dynamically, and exchange information about status with a user interface that acts as configuration UI and policy agent. Networkmanager has gone through a large redesign between the 0.6 and 0.7 version, including the necessary API and DBus interface changes. Not without advantages though. I personally didn't really like networkmanager's behaviour in the past, found it too random, too much getting in the way. Networkmanager 0.7 is better in that regard, it doesn't drop my connection all the time for a start, it stays online while you log out and operates mostly within the bounds of what I deem sane.

One of the projects I've been working on over the last couple of months is the networkmanager plasmoid for KDE4. Will has put the infrastructural bits and pieces that are needed to work with networkmanager 0.7 into place. There is the networkmanager backend for Solid, KDE's library for interaction with hardware, but also all the different configuration interfaces for all kinds of network access.
During development of the networkmanager plasmoid, I've often used the GNOME nm-applet. It does the job quite well and is a reliable interface to networkmanager. Something I find a bit confusing is that it offers two context menues, one on right click and on