Last Performance Blog

According to a reply on my previous blog, I could just as well test if having my hamster run in his wheel would increase drawingspeed as long as I don't use valgrind and cachegrind.

Well, I've never used those tools before, but hey. Let's give it a try.

Valgrind and Dolphin (resizing all the time).
Well, valgrind talked about memleaks. I get that. The details of that, however, don't tell me much (of course, that's an understatement).

==21180== LEAK SUMMARY:
==21180== definitely lost: 8,383 bytes in 342 blocks.


The output for individual parts where something is lost is like this:
==21180== 216 bytes in 1 blocks are definitely lost in loss record 175 of 257
==21180== at 0x4021765: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==21180== by 0x56BB885: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==21180== by 0x56B88CF: _XimRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==21180== by 0x5699517: XRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==21180== by 0x503F73D: QXIMInputContext::QXIMInputContext() (qximinputcontext_x11.cpp:361)
==21180== by 0x503E4A5: QInputContextFactory::create(QString const&, QObject*) (qinputcontextfactory.cpp:120)
==21180== by 0x4B928F1: QApplication::inputContext() const (qapplication.cpp:4541)
==21180== by 0x4BD5046: QWidget::inputContext() (qwidget.cpp:245)
==21180== by 0x4C051CC: QWidget::destroy(bool, bool) (qwidget_x11.cpp:853)
==21180== by 0x4BD7D8F: QWidget::~QWidget() (qwidget.cpp:1264)
==21180== by 0x4EADB04: QLineEdit::~QLineEdit() (qlineedit.cpp:357)
==21180== by 0x4E76C8A: QComboBox::setLineEdit(QLineEdit*) (qcombobox.cpp:1599)


Above is with QtCurve as style, btw.

Well, I think that would explain it all if I just had more brains. Unfortunately, I don't, so let's go on to kcachegrind. Again with QtCurve, which, as I mentioned before, draws a bit faster than Oxygen.

KCachegrind
Well, what can I say. Lovely graphs, that's for sure. As far as I can tell, this tool shows where the app is spending it's time. I guess the 100% ld-2.7.so doesn't mean that's what the app does all the time.
The < cycle 13 > I see as LibQtCore.so.4.4.0 doesn't explain much either. Digging down (this kcallgrind tool is pretty cool, even though I don't really understand it) I seem to see a lot of calls to QWidgetBackingStore?!? And there are over 2.4 million calls to isPaintOrScrollDoneEvent, but the % spend there (if that's what the % mean) is just 1.5%... Hmmm, again - big ?????

Or is that second line, self, the one which shows how much a function is called? Sounds like it could be true. In that case, at least 12% of the time of Dolphin (when resizing all the time, of course) is spend in varous libc-2.7.so calls.
The funny thing is that the orders for the libc-2.7.so functions seem to come all from the same Qt function: QListView::paintEvent < cycle 13 >. And then some KFileitemDelegate::paint things.

This could mean QListView is the problem (did I say something about QScrollBar? Does that have something to do with QListView?)? Or does this mean my hamster simply didn't run fast enough?

I'm sorry. This does not make anything clear to me. As I said before, I'm going to wait for someone actually knowledgeable in this area to say something.

A commenter on my previous blog did use callgrind, btw, but his findings were not very clear (to him, I mean, they were obviously not clear to me anyway).

Luckily I received also a few private mails, ranging from "Xephyr does indeed weird stuff, Qt4 apps draw much faster in it than in plain X" to "go on blogging about this". Which I won't, btw, as I never intended to go this far. Sure, many ppl seem to find it interesting, but the complaints about "don't whine, do something", while not making me happy, have a point. I can't do anything, so someone who actually CAN should take over. Or not, in that case - well. Shit happens. Maybe just use GTK apps, then. I had to install a bunch of GTK libs for kcachegrind anyway, for some weird reason:
libgnomecanvas, libgnome, libbonoboui, gnome-keyring, libgnomeui, graphviz, gail, gconf, gnome-vfs and libbonobo (including a bunch of errors about missing gtk things and other stuff, even though kcachegrind works fine)
Why KCachegrind needed that stuf: please let me know. I'd love to get rid of it again.

Edit: aah, probably optional (but apparently compiled in) dependencies of Graphviz... Weird, the graphviz page doesn't mention them, so I still think it's faulty.... So far for Arch linux is mean & lean.

Oh, and Happy new year for those who already are in 2008 when they read this ;-)

Edit2: And the Gwenview author, Aurélien Gâteau, just emailed me to ask me to test some improvements to the panning in Gwenview 4 he made in response to my blogs. So I did test it, and I am happy to tell you all the slower panning in Gwenview in KDE 4 is totally gone - the KDE 4 version is now as fast as the KDE 3 version! Thank you, Aurélien!

Edit3: make the blog sound less like I'll be crying all night because someone said bad things - after all, that's not the point, and I don't want to sound like I won't blog anymore if ppl are mean...

performance and Qt 4.4 again

My previous blog resulted in an large amount of reactions, many of which warrant a reply from me.

I blogged about bad drawing performance, and the big question I had was: what was causing it.

Firstly, a few video's were posted which showed the issue:
http://bw.uwcs.co.uk/kde3_resize.ogg
http://bw.uwcs.co.uk/kde4_resize.ogg

I hope the person posting them won't mind the bandwidth sucking....

Now I ended my previous blog with mentioning this issue seemingly was a bug in Qt, and more precisely, QScrollBar, based on the profiling one reader did in the blog before that. But in the comments section another issue came up: first mentioned by Benji, who discovered to his surprise his 3 year old laptop with integrated (Intel) graphics performed better than his NVidia GeForce 8800GTS... Quite a clue as to where the issue might be, I'd say. An article talking about the upcoming (now out) NVidia driver mentioned quite a huge improvement in XRENDER performance, so that might make a difference. I've compiled and installed the driver, and unfortunately, no visible difference. I can show the graph, but just take my word: Konqi still takes between 10% and 20% CPU when scrolling (that's with dualcores, so it's actually between 20 and 40% of a 2.4 ghz AMD core...). Resizing still barely goes over 5 frames a second (mostly a lot less).

So it probably isn't the NVidia driver - somebody with an old ATI Radeon (pretty good FOSS drivers available) also has the issue. But I do wonder about the apparently good Intel performance. More convincing against the NVidia-does-it case is an comment from Rui, who mentions sub-standard Qt 4 performance on Mac OS X:
Hi, FWIW, on Mac OS X, the last.fm client, which bundles some version of Qt4, is also a lot slower redrawing itslef when resizing than, say, a Finder window, even if said Finder window is displaying the new coverflow view of files.

I'll try getting some numbers later. Maybe checking Qt4's performance on windows would be constructive too. By checking on other systems we are eliminating a whole bunch of probable places where the slowdown could be occurring. This kind of performance problem is quite difficult to measure especially because there are so many variables going under (system frameworks) and above (the app itself) Qt.

So, were are we at. A short overview:

- It is not the Oxygen style.
- It is not Qt doublebuffering.
- It is not 3D/compositing stuff.
- It is not the (lack of) alien widgets.
- It is most likely not the XRENDER performance of the NVidia drivers (but maybe Intel does something right?)

So, we're back at Qt again. Why does Qt 4 drawing seem to perform so much worse on some hardware? It could be that Qt 4 is much more dependent on hardware acceleration - and if that's not done properly by the drivers, drawing suffers. I wouldn't know. But if it IS drivers, the new NVidia driver should probably fix it - and it doesn't. I know there is more to drivers than just XRENDER, so I should probably let others talk about that. Actually, that would be a good thing - maybe a graphics guru (our own Graphics Ninja perhaps?) could chime in, say something?


----DISCLAIMER
Now I also have a disclaimer, as my previous blog also resulted in a comment blessing me by the name of 'whistleblower', and someone else wasn't to happy with the "this is Qt's fault".

I think I was clear enough on this, but I want to repeat it: I don't think this is a huge issue. Sure, it looks bad, but that's about it. The faster application startup we have in KDE 4 far outweighs the slower drawing. Performance is much more than drawing, and imho having to wait for an application to start is much more annoying.

Secondly, my measurements are of course entirely unscientific. After all, the difference on can see with the bare eye must be relatively large to really count. And it might be that there isn't one cause but there are several causes. Maybe it is a combination of the double-buffering, bad drivers, Oxygen style and lack of alien widgets. But I have tried resizing dolphin with the QtCurve style and Qt 4.4 (aka alien widgets) with the new NVidia driver - and I still clearly could see it draw. Oh, and turning the double-buffering of leads to 100% cpu usage when resizing even a slight bit so that won't help either ;-)

Third, maybe it isn't Qt's fault at all - it might be that the way Qt4 works (more hardware acceleration, more use of animations, transparency, etc) just exposes bad performance in X.org and/or graphics drivers. Seriously, I find that very likely. Seeing how many Qt developers seem to care about performance, it seems unlikely they would release something which is so much slower than Qt 3. So it is very well possible it works fine on THEIR hardware. Apparently, the FOSS Intel drivers fare pretty well, so maybe they all have these nice MacBooks and such ;-)

Last, I didn't file a bug. First because I'm still trying to figure out what exactly causes this, and secondly I'm simply not knowledgeable enough to start profiling apps. And also because this process seems to work rather well - with the help from the many readers of this blog, I feel we're getting closer to finding the reason of the issue.

So, while I look forward to a comment from someone who can tell me he/she found the issue, this is in no way a blocker for KDE 4.0 or a horrible thing for Qt 4.x. What I would do is recommend to the KWin developers to set KWin to NOT display content in resizing windows by default. That wouldn't look incredibly cool, but it would look far better than horribly slow resizing windows. Lubos? Rivo? Are you guys reading this?

performance and Qt 4.4

And again I blog about performance in KDE 4. In my last blog about that, I did express the hope the Trolls would be able to fix the issue. So, today, I tried to test the cool alien widgets which are supposed to fix flicker-when-resizing! To cut right to the chase, no, it didn't work. Blegh.

I know I'm a sucker for speed. I want my computer to wait for me, not the other way around. I mean, a machine which can easily do millions of computations a second should be fast enough to keep up with my freakingly slow brain, right? It can take up to 1/10th of a second for a signal to travel from one end of the human brain to the other - that's not even the same league as my PC is playing in... Not to mention it has two cores and 3 GB of ram to go with that insane clockspeed ;-)

So I have played with kernel patches (Con Kolivas' work is and has always been amazing in that regard). I've tried Gentoo (aw, yes, I did...). With newer GCC, X.org and linux IO and process scheduler versions, my KDE got much more smooth. Not perfect, no - but my biggest gripe, application startup speed, well - that's covered now. KDE 3.5.x didn't do badly, but if you see the difference with KDE 4 - you're gonna be surprised. Really.

Unfortunately, as I found out some time ago, drawing performance has gone through the drain in KDE 4. Now that issue is less important. Having to wait for an application to start up is annoying - you actually have to wait. If an application redraws slow, that means resizing a window won't look good. That's about it. Not a huge deal, if it wasn't for all the cool eyecandy in KDE 4 (oxygen, animations). Really, it doesn't fit very well if your apps look bloody cool but resizing causes epileptic seizures... Besides, it's not only the resizing, but also the panning of an image in Gwenview and the autoscroll feature in Konqi. The latter manages to use up to 40% of one CPU core, and the former also redraws visibly slow.

As a non-hacker, I'm not sure all issues I find are even related - but hey, one can try to figure out the issue anyway. So, here are suggested reasons for bad performance:
- Oxygen style is slow. Yep, it's a bit slower than for example QtCurve, but not much. Not THE problem.
- Qt doublebuffering is slowing everything down. Nope, disabling makes the application flicker horribly, but it won't be any faster.
- 3D stuff is slow. Sure is, but I ran the apps in KDE 3, no compositing. Not the issue.

So, now I wonder if the slowness could be fixed by the Alien Widgets, which have arrived in Qt 4.4 snapshots.

I downloaded a Qt 4.4 snapshot (today's snapshot, from 29-12-2007), compiled and installed it, and recompiled KDE with it. As I already said - no improvement, at least not as far as I could tell. Sure, with QtCurve the issue did get better, but still - if you have the KDE 3 dolphin resize almost entirely smooth, while the KDE 4 one paints visibly (I could count the number of repaints when resizing if I wanted to) - not good.

The panning in Gwenview isn't faster either, but I guess that doesn't have much to do with the alien widgets thing. I couldn't test konqi scrolling, it doesn't load webpages with Qt 4.4 ;-)

So, it's not the Alien widgets which will come to rescue KDE 4 from bad drawing performance... I see currently one possible reason for the bad speed. An anonymous reader pointed out in my last blog how Qscrollbar isn't that fast:
It seems related to QScrollBar.
Profiling konqueror in auto-scroll mode, I obtain 50% (!!) of the time spent just repainting the scrollbar.
I found no bugreports for this in TT's bugtracker (if the anonymous reader is reading this, maybe he/she should file a bug?). I'm afraid KDE 4.0 and 4.1 will have this issue - IF this gets fixed, it most likely will take until KDE 4.2 is out for this to get into the users hands. Unless the Trolls decide it's important enough for a bugfix release, of course... Personally, I hope so, this really looks bad.


Further info:
I use the following additional cmake-options in my .kdesvn-buildrc:
-DKDE4_BUILD_TESTS:BOOL=OFF -DCMAKE_BUILD_TYPE=release
-> that should lead to no debug symbols, if I understood some recent threads properly.
I've tried several styles, from the with Qt included clearlooks, QtCurve and default Oxygen. Yes, Oxygen is a bit slower with its cool background gradient, but it's not like the other ones are smooth anyway.

One last thing, of course all this might be my fault. I think I do know a little about compiling and stuff, but I'm not a code writer, and profiling is scary for me. So maybe I've made a horrible mistake, and the KDE 4.0 packages my distribution will provide soon after the release (love the rolling release schedule in Arch) will be as fast as a fox. And I don't mean FireFox, as that must be the most horribly slow painting application we have on linux (and windows and Mac OS X).

Let's hope so.

I wrote about the performance of KDE 4 some time ago, and I'd like to revisit it.

After a few threads about debug builds and release builds on kde-core-devel I figured I was wrong in my previous entry, KDE 4 couldn't easily be build without debugging symbols. So my build WAS a debug build. But now it's possible to have it clean and fast, and I did indeed see an increase in performance when trying it.

Apps start up even faster, it's rather weird to see an application which always took a noticeable delay to start up now pop up like its a basic calculator ;-)

Drawing is also a bit faster, but still clearly not as fast as in KDE 3. Resizing dolphin on KDE 3 is almost entirely smooth - very unlike the rather unpleasant experience on KDE 4. Gwenview is a bit faster, it doesn't draw an image visibly when you drag it anymore but clearly isn't as smooth as the KDE 3 version. It IS faster loading large images though, a 6400x3200 image loaded in a snap (!) while the KDE 3 gwenview made me think it got stuck...

And here's a new Konqi-auto-scrolling picture. It starts with XPLANET (nice 20, yes), then 5 seconds pause, and I start scrolling the Konqi from KDE 3. You don't see a visible difference in CPU usage... When I increase the speed of the scrolling, there are some very small spikes but generally the CPU is still barely used.



The picture for KDE 4 is different - approximately 10% of my cpu is needed to scroll a page slowly, which increases to 20% when I increase the speed of scrolling.

Notice that these numbers DO represent a decrease compared to my previous test, which showed twice as high CPU usages in KDE 4. So it might be no more debugging, or some performance work - either way, Konqi got twice as fast already ;-)

As discussed on the other blog post, this is all with a dualcore 2.4 ghz AMD, 3 gb ram, proprietary NVidia drivers (geforce 6600) and NO compositing. Tests are run in a KDE 3 environment. Yes, double-buffering is on in Qt4 - as it should be, it looks horrible without... The whole area flashes when scrolling.

One person mentioned a potential scrolling bug in Qt4, which makes it redraw the whole area when scrolling. This could indeed explain the flickering without double-buffering and the performance problems, I guess. Hopefully a new Qt version fixes this, I found quite a few scroll-speed related bugs in the TT bugtracker.

I think I can conclude the performance issues with drawing are not as bad as I depicted in my previous blog, and it's very well possible they can and will be fixed. Meanwhile, KDE 4 performs amazingly well in many other areas - most noticeably application startup.

EDIT: With some help (see comments) I was able to compile QtCurve for KDE 4, and tried it. Some argued the slow drawing when resizing might be due to Oxygen behing slow, and that showed indeed at least half true. Dolphin resizes faster with Qtcurve - but the KDE 3 version is still much more smooth.

Performance 3

Hi all,

After some raving blogs about how memory-efficient and fast KDE 4 is, I decided to test something myself.

I felt there are regressions in drawing performance in some apps, and I tried to quantify that a little bit. Of course, entirely unscientific, but the patern should be clear... For those who wonder, as far as I can tell, debugging is off in my build and my hardware is pretty nice - a 2.4 ghz dualcore AMD with 3 GB ram. It was all done in a KDE3 environment.

Procedure:
1. Start Ksysguard (the kde 4 version of course, as it looks much cooler), and minimize.
2. Do some Stuff.
3. Use Ksnapshot on Ksysguard ;-)

I tried Konqueror and it's autoscrolling feature (shift-down-arrow) and Gwenview (drag a big picture around). Here the results:



As you can see, Konqi in KDE 3 uses barely any CPU over the baseline when autoscrolling. The KDE 4 version, on the other hand uses quite some CPU.



Here I pan (is that the right word?) the image around. As you see, Gwenview 4 easily uses 100% cpu (one core) and is visually very laggy, too. The KDE 3 version looks entirely smooth, and indeed doesn't get to use a cpu core fully ever. Again, a performance regression.

Well, what can I say. There sure is still a lot to optimize, and maybe these issues can be fixed very easily. After the positive blogs about memory usage I became rather sceptical - I mean, with so much code changed and so many new features - could KDE 4 really be that much faster? Now I didn't test memory usage, which might very well indeed be much better - but at least these two apps got slower in the rendering/painting department, so here's the balance ;-)

Other remarks: yes, ksysguard uses 20% cpu when drawing 4 sensors and put full-screen. Awful indeed, but the KDE 3 version doesn't do much better, and minimized the cpu usage is reduced to almost nothing. Besides, it looks damn sexy, doesn't it?
The big spikes marked 'xplanet' - you guessed it, it's xplanet, which updates my desktop picture every 5 minutes using some pretty pretty big planetary pictures - so it takes a while.



One more thing. I played with the colors in Oxygen again. And in my humble opinion (those who know me know I'm rarely humble, but whatever) Oxygen rocks, it really does. It is one of those rare themes which looks amazingly good in a wide variety of colorschemes. Despite the fact there are a few unfinished things (but that's true for almost all of KDE 4) it is imho the best theme ever made. Original (it looks as much as Vista or Mac OS X as those look like Windows 95) and brilliantly smooth.

The best thing about Oxygen is some quality it shares with Dolphin: it grows on you. At first, Dolphin didn't appeal to me - I love konqi as a filemanager. And I wasn't impressed with Oxygen much either, I normally prefer very glossy themes like liquid or Polyester. Oxygen, I thought, was kind'a boring.

After using it for a while, I've grown very dissatisfied with any theme on KDE 3 - I find Domino, one of the most modern KDE 3 themes, bearable, but that's about it. And I find myself using Dolphin more and more, to the point that I installed the KDE 3 version on my main system...

So, to those bashing Oxygen, Dolphin and Kickoff - wait until you've used it for a while. You'll probably discover you don't wanna go back...

more ramblings about vision and future ;-)

In the comments section on OSnews someone noted how it would be very hard to gain marketshare for FOSS due to the dominance (and use thereof) of Microsoft. I thought my reaction was worth posting as a blog ;-)

Indeed. Uptake of linux will go slow, and not at all if Linux doesn't offer advantages to both developers and users. We need to be clearly better than Microsoft and Apple. We need to out-innovate them and bring the latest technology at the earliest possible moment.

Yet it happens to be that we're particularly good at these things, and as our ecosystem grows, we grow faster and stronger. FOSS development techniques, unlike proprietary development models, scale pretty well.

As more and more companies are joining FOSS one way or another, we will cross some threshold were a FOSS system will have such clear advantages it will be impossible to ignore. Lower costs, better availability and more capabilities; and a more healthy ecosystem with more competition and smaller, more innovative companies.

In the long run, I don't think MS and the other proprietary vendors will be able to stop it - unless, UNLESS they can do so through legal and political barriers. But the tide is turning against them - Europe is slowly getting committed to FOSS, and it is keeping a close eye on abuse of marketpower - which is the only real asset Microsoft has against FOSS.

The above is why I think what is going on with KDE 4 is crucial. I've blogged before about that, and I also talk a lot about these things on forums... One on of these posts, I wrote about Novell and how they are (imho) wasting resources (re)writing stuff for yast in GTK. (probably worth reading before continuing. I didn't want to paste all my posts here...)

And one of the comments was that I was trolling. Now, I agree I wasn't very nice. Saying Gnome release announcements feel like a timemachine from the KDE 3.3 era - a bit harsh, I know. And also of course an exaggeration - there is regularly stuff in there which was not in KDE 5 years ago. Anyway. I did reply on it, but I think Segedunum put it much better:
Ahhhh, the emotive question of open source desktops. You can only go so far before pointing out the truth, and when you do, others are simply not going to like it -).

Aaah well. Time will tell what happens. At least we have big plans.

Another thing, as my previous dwarfhamster died (did I blog about that?) and I went through the mandatory period of mourning, I got a new one. This time not from Animal Protection (or whatever you'd call those guys in english, too lazy to look it up) but from a pet store. I'm not too fond of those, as they generally don't treat animals too well, but OK, it was a gift by a loved one ;-)

So the question to ya'll. How should I name him? Not tux or something silly, nor those horrible names like 'sniffy' or Blacky or whatever painfully cliche names ppl seem to come up with.

Putsy and talks in Dresden

So, I will move to Amersfoort this weekend and I'm terribly busy with my new job (but it's also really interesting and I'm making many mistakes so I learn a lot).

And it shows - I haven't blogged in a week, even though there was a lot to blog about...

For example, I'm sad to tell you guys Putsy, my little dwarfhamster, passed away last week. He had an infection, probably indirectly caused by the cat who threw the cage on it's side. Putsy most likely got smashed somehow, and the vet was unable to get her to drink anti-biotics. She already went into a state of hibernation, and died the next day (just before I left for Linux-Info-Tage in Dresden). I was a bit sad while driving to Dresden, but meeting the guys there made up for it.

Speaking off Dresden, I gave a talk at Linux-Info-Tage. Here a little (german) writeup about it (including a higher quality version of the dolphin animations movie which also is on Youtube). Ah, and Kubuntu-de.org also wrote about the Dresden event. Here the picture of me which I consider best. Even though this one doesn't show how I did actually shave, like I promised.


And where were you, Merlin?

shaving...

OK. Next time I give a talk (saturday) I will shave.

*click*

Konsole performance

I had a discussion about the speed of Konsole with some Gnome users at a CodeYard meeting. Some testing on the spot revealed gnome-terminal was much faster. So I tried to test some stuff at home, too - see if anything has changed with KDE 4.

Well, yes, Konsole got almost twice as fast - still slower than gnome-terminal, though.

[root@wietbak log]# time cat messages.log.4
(lots of output)
real 0m1.923s (Konsole KDE 3)
real 0m1.077s (Konsole KDE 4)
real 0m0.412s (gnome-terminal 2.18)

But there are differences - some files show different results.
Take the output of another file, dunno what it's supposed to be but it's in /var/log, too, and contains many weird characters like these: ���E�Ms� �

[root@wietbak log]# time cat btmp
real 0m1.030s (gnome-terminal 2.18)
real 0m0.819 (Konsole KDE 4)
real 0m0.711s (Konsole KDE 3)

So for this file, the result is exactly the opposite, though the differences are much smaller.

Weird, weird.

Let's cat all files in /var/log, then, see what the overall scores are:

[root@wietbak log]# time cat *
real 0m10.797s (Konsole KDE 4)
real 0m18.940s (Konsole KDE 3)
real 0m6.524s (gnome-terminal 2.18)

real 0m16.423s (xterm)

For those who want to know how xterm does... Besides looking horribly (no anti-aliassing, and flashes horribly while scrolling), it sucks only slightly less than Konsole from KDE 3 in terms of speed.

Anyway, that confirms the first results. Konsole got almost twice as fast, but gnome-terminal is still a lot faster ;-)

Now of course Konsole kicks gnome-terminal in terms of features, but speed matters too ;-)
I'm not unhappy with the current speed (hey, twice as fast, that's good!) but there apparently is room for improvement. So let's see what the future (KDE 4.1?) brings...

On vision and Future

The talk I gave at the Dutch Ubuntu Release party marked a point in time where my thoughts about the Vision and Future of KDE have become solid enough to write about them. Of course, many have preceded me - like Aaron, Troy and Wade. And I have been greatly influenced by my research in the area of Social Innovation and Open Innovation at the Dutch research institute TNO. So this doesn't come out of nowhere at all, I've just merged and aligned these different ideas somewhat.



This image by Wade is quite true. Even though a community generally doesn't have the focus a company can enforce from its employees, KDE has a vision. We want to go somewhere, as a community. Not everyone has the same ideas, sure. But out of all these different individuals and sub-communities within KDE, with their own opinions, plans and roadmaps, a big picture appears.

I don't claim I can express exactly what KDE wants for the future - I'm just a member of this community. I have my own ideas, and I'm influenced by my own knowledge about many things - or lack there off. But ideas grow. What KDE is growing into might never have been imagined by anyone who started on this journey. Yet I think the implications of it can be quite clear.

The most simple incarnation of the plan for KDE 4 is "improving our framework". It means we are going to make the KDE libraries better. Add new functionality, improve the existing stuff.

Aaron Seigo has been more verbose, speaking about making it easier to join KDE, to attract new developers. By improving documentation (techbase), but also by making KDE technology available to more people. It is one of the main ideas behind the development of Plasma, a new widget-based framework which replaces the desktop and panels in KDE 4. It is easy to develop for plasma, because it offers a lot of high-level functionality. Without having to worry about the complexities of data gathering, the writer of an applet can focus on the representation - so more bright ideas can be expanded upon. Meanwhile Kross, the new library in KDE 4, allows application developers to support more than just one language for writing extensions and plugins. If you're not fluent in Python, you can use Javascript, or Ruby... The result is more people can contribute - which leads to more innovation.



Innovation is one of my biggest interests (professionally as well as personal), and I have always enjoyed the innovative culture in KDE. We're open to ideas, very open. Of course, this is a property of most F/OSS projects, Raymond knew that already. This has been noticed in management circles too.

So, there's a new management trend in town: Open Innovation. Around the world, MT's are trying to figure out how to take advantage of it. Open Innovation is about opening up to and working closely with customers and suppliers to facilitate innovation and new ideas.

And it works. FOSS has proven to be not just a superior development model for software, but the freedom is also conductive to innovation. Of course, this is what every good open source project does. We're a natural at that.

But we are doing more. Yes, the work by Aaron (and many others) makes it easier to contribute. The improvements to the KDE libraries, and the support for more and easier languages to write full applications in does the same. Yet, there is another big thing coming which will help us to become more innovative: The Pillars of KDE 4. These new technologies we are introducing in KDE 4 like Decibel (communication), Phonon (multimedia) and Akonadi (PIM data) will increase our innovative capacity. Which is, to quote myself: "the capacity of an organization to generate and use ideas (inventions) to perform effectively" [1].

What is an invention? It's simple. Inventions are the connection of existing ideas and technologies into a new one. Now imagine. Providing people with bright ideas with incredibly powerful, high level components they can connect and combine in any way they want - all this within an atmosphere highly conductive to innovation. No management, nobody telling you what to do, no paperwork. No limitations.

See where this is going? We are creating a perfect opportunity for the Free Desktop to leap ahead of the competition. Apple and Microsoft won't be able to keep up with us... Ever.

Does every KDE developer realize the full potential of this? Not all of them, maybe. But you'd be surprised how many grasp at least a big part of this future. And not only our own people, but the Free Software community at large is aware something big is going on. We're already the second-largest FOSS project, but we're growing like crazy - new developers join us almost daily.

High expectations for KDE 4. No, not for 4.0 - I think most people already understand 4.0 will just be the beginning. Not terribly stable. Nor fully complete. But it will have these foundations in place and it will enable us to start innovating.

Boy, am I looking forward to the future!



[1] my unfinished paper about "The effect of psychological safety and climate for initiative on the effectiveness of explorative and exploitative innovation" (translated).

accelerated rendering

Of course we have some experts in this area in the KDE community (zack is well known, but I wouldn't forget about Mosfet or the people working on KWin.

Now my understanding of this stuff (being not a developer) is always very limited - which does nothing to lower my interest in them... So when I read this blog on the gnome planet, I found it very interesting. I mean, it has pretty pictures, you know... And hardware accelerated rendering, preferably using openGL for everything (or at least more than we do now) is something I'd love to see - it really sounds like a big thing in terms of performance ;-)

Now the person who wrote this blog isn't very positive about this, but I agree with some of the comments there - OpenGL probably won't go away. Or would it be possible to integrate it with toolkits? This blog by Daniel Molkentin talks about using just the normal Qt api, yet the drawing goes through OpenGL. Sounds like neat, but what about all the other drawing in KDE/Qt?

The point of this blog is mostly that I haven't read about lower-level stuff like this for a while in the KDE blogosphere, and I'd love to see that change ;-)

How's the status of Arthur? Animations KDE4 are still kind'a disappointing in some areas - at first I blamed compositing (and it does make matters slightly worse, yes, but just slightly). Take the run dialog - it has an animation when you click options. Lovely, but it never works smooth, even the 100th time (you'd say it has cached stuff, and it has, but it's not enough). It's not just having to resize the window (even though that's bad), but even after that it's not exactly smooth.

And the background gradient in Oxygen has the disadvantage you often see a plain background flashing when resizing or animating things. As I see the CPU usage max out, I wonder if the GPU is used for any of these things - and if not, why not? Where's the bottleneck? X, Qt, other infrastructural stuff, or can't the GPU help at all?

So, who's involved in these things, and willing to write about them - what can we expect for KDE 4.0 and the future? Will these things be solved, is 3D hardware acceleration gonna help us anytime soon? When I see the animations in Vista - they're very smooth, and CPU usage keeps low, so it seems to me they've got the issue solved, haven't they?

Colors again

A bit more work went into the Colors configuration, and imho Matthew Woehlke is doing a great job there. Today I played a little with the 'contrast' slider there, which gave the following screenshots, starting with Oxygen's own colorscheme, and then the 'Midnight Meadow' scheme.

Oxygen Low Contrast

Oxygen High Contrast


Yeah, not a huge difference. Personally, I prefer the 'Beos' color scheme, here in high contrast:


Here we have Midnight Meadow:

low contrast


medium contrast


high contrast


And last but not least, about Plasma performance. Some time ago, KNewsTicker was ported. Now there is a discussions going on about the release status on the KDE development mailinglist, and the KNewsTicker developer argued Plasma performance was bad - his applet used 15% on a 2 ghz Core2Duo, while just scrolling some text. Well - either he fixed the performance issue, he had a configuration problem, or someone else did something cool - but I can't reproduce it at all:



Further complaints about plasma performance (high cpu usage when moving plasmoids around) lead to Aaron testing the difference between KDesktop in KDE 3 and Plasma in KDE 4 - KDesktop used 3 times the cpu for moving an icon than plasma for moving a (transparant, svg, good looking) plasmoid... And to finish the 'performance sucks' argument off really well, Aaron mentioned there still is a lot of lowhanging fruit to fix, and Qt 4.4 is gonna speed things up a lot. Well, if Plasma performs as good as KDesktop with superkaramba, you won't hear me complaining (it does a LOT more). And it really looks it does - not just from Aaron's comments. Try KDesktop and Superkaramba with a few applets and be shocked (and that's not just superkaramba, all applet things in linux suck in terms of cpu usage - looks like Plasma is soon going to be the most sane implementation available).

BTW - see how cool KDE 4 looks ;-)
This is svn from a few hours ago, so the latest & greatest. And after playing with it for some minutes, I must say the main reason I don't switch fully to KDE 4 is because I installed it as a separate user, and I would have to migrate it to my current account or migrate my data to the other account ;-)

KDE 4 - does it work or not?

After a few blogs which where rather positive, we're now also seeing blogs and comments much more negative (I don't feel like linking to them, sorry).

Aside from some speed issues (which I don't see, frankly KDE 4 is clearly faster here in many aspects - see my previous blog), 90% of the complaints is about the state of Plasma

Now I agree Plasma is a big thing, important for KDE - but judging the whole of KDE by the part which is least finished - I think that's unfair. And to be honest, 90% of commments about Plasma are about the panel with the still-very-basic taskbar and the missing menu. The menu still is in playground (could be it was just moved into kdebase, btw) and well, yes, the taskbar - it's not very ready either.

But come on. Think about it. You're complaining about 10% of 10% of KDE 4. Actually, much less, as I've made up these numbers :D

So how much time would it take to write a decent panel, provided the current state? And Plasma will still see a lot of work, it's not frozen yet, unlike the rest of KDE. I'd rather see everyone trying and talking about all the new good stuff instead of complaining about the almost-last portion of KDE still in flux...

When I show people the state of Plasma, they're like "hmm, that's not good". So I then proceed to show the Edu and Games, cheers them right up. And there is Dolphin, Ksysguard, Gwenview, Okular, Kolourpaint, KRDC, Konsole - all those apps which have seen so many improvements. Or these small things, like the file dialog, the character selection dialog, the shortcut dialog... I don't hear anyone raving about those. Is that just because they COULDN'T get past the missing menu and not-so-great taskbar applet? Please...

We should be realistic (KDE4 won't be perfect, and will have regressions) but all this complaining doesn't do much good either. Feel free to report bugs for those things which are supposed to be finished (I just emailed the kwin developers about the not-working window-shortcut feature). And join those working on the things still not ready. And complain to your mum.

Take care.

Who did this?

Here another "KDE4 is really usable" blog. Well, I just want to point that out up front. Oh, and my day was different from Wade's. Yesterday I gave a talk to dutch students about KDE 4, I didn't get machette's to my head. Aaah well, everyone's different.

The real topic is something else, though - I wanna know who did the following:


That person deserves some kudos. I haven't seen any blogs or whatever about it, but I think it's a great job. Solid Usability Work the KDE Way (tm): make it easier to use and more powerful at the same time. Yes, it's a bit harder, but much more rewarding to not take the easy route of 'dumbing down'. Nice work... Of course, there is more to do, maybe the person who did this can spare some time on the 'edit toolbars' dialog as well.... Currently drag'n'drop is broken ;-)

Another thing which I wanted to mention: Cornelius said he was amazed by the speed of KDE 4 apps. Now I took that with a grain of salt, as I hadn't seen any amazing speed yet - Okular was slow, I had seen konqi using 100% cpu and still stutter on scrolling, KWin didn't exactly go smooth... But while making the above screenshots I used kwrite, and indeed - kwrite4 starts faster (feels at least twice as fast) as kwrite3 (both in my kde3 session)! And other apps do the same. Gwenview is like 10 times faster, and konqi4 seems faster without pre-loading than konqi3 with! Konsole seems a tiny bit slower, though.

Sure, you don't want kbuildsycoca4 to run first, but after that's done - applications are wonderfully fast. It's like someone turned 'speed' on in Trunk, somewhere in the last week... Whoever did that, nice work!

Now, the last thing: colors. I've just been trying the colorscheme things, and they work great - see the following screenshots (yes, the second one, called Beos(?), gives the higher contrast many ppl seem to want from Oxygen).





The oxygen style also does a pretty nice job on darker colorschemes (unlike most KDE3 styles):

picture viewers & widgets

While writing stuff about KDE, you have to make screenshots. And often modify them basically (resizing, converting, stuff like that). So I get to play with some image viewers like Gwenview and showFoto and with image editors like KolourPaint & Krita. Kolourpaint and Krita are rather complementary. Kolourpaint, after all, is basic, quick and easy to use while Krita can do the heavy lifting. Gwenview and showFoto, do have more overlap, but Gwenview is faster, smaller and does the basics, showFoto is more featureful. Now I know there are more imageviewers in KDE (kview, kuickshow, and some third party things like squirelsomething) but I'm glad I don't have them installed - I'd rather see showfoto as fast as Gwenview, and I'd ditch Gwennie (or the other way around). Now Gwenview gets some love for KDE 4, and as far as I can tell, it's going to be the default imageviewer. Maybe. Why maybe? Well, I'm unsure - it seems Okular also wants to be an image viewer, right? On one hand - cool - annotation. But I'd rather then see the annotation stuff shared between KDE apps with Nepomuk or Strigi or something...

Now on to something more positive. Someone started a discussion on the kde usability mailinglist. It's rather long, but I became interested when the pretty pictures came. Someone pointed to this problem:







I found a solution which is already used in KOffice:




It looks pretty good, but there where some comments - discoverability isn't great. A right mouseclick is needed to be able to enter text, and it isn't obvious that it is possible at all. Plus, the guys wanted a drop-down. So Hans Chen made a mockup:



I'd say, with a editable combobox instead of a 'hidden' one on hovering (see top right mockup), it's great and should be the default zoom thing in KDE 4... ;-)

demo videos

We had a booth at T-DOSE, yesterday and today. I made a bunch of movies, to put them in a playlist and let it run.

Unfortunately, my laptop's videodrivers act rather weird, so xine gives a blue screen to many of the movies, vlc crashes, and mplayer can't properly resize the movies, so it leaves the previous one on the screen. KMplayer does a great job, but I've not been able to get it to just PLAY (let alone loop) the frickin' playlist (WTF is it for?!?). It just stops immediately after each video. Blegh, spend a lot of time on these issues :(

So however useless these video's where, I'm putting a few of them on youtube for your viewing pleasure. Here is the first one, showing off Kalzium.



Edit and another one, KSudoku.


Indeed, the edu apps and the games make for excellent videos ;-)

cooperation

Some time ago, there was a discussion on the KDE PIM mailinglist. A certain Michael, apparently a big fan of the RS (RetroShare) messenger technology (serverless/p2p stuff), came asking if it would be possible to integrate that application (Qt-based and FOSS) into KDE PIM. He noted how Google Mail has Google Talk integrated, and how Thunderbird is also working on integrating IM.

Others on the mailinglist explained him there was already some integration with Kopete. He then started talking about OO.o, which apparently was looking for an email application to integrate into the suite, together with IM (and probably cooperative stuff as well). He pointed out KMail and RS messenger would have a shot. At a certain point, I said to him:

Let them work with the other freedesktop standards instead of doing ad-hoc integration. Working with Telepathy and Akonadi would be much better, as that would mean integration with all apps that work with those infrastructures, so much less duplication of effort.

He then asked me if I would like to help translate RS to dutch, and I did help a bit with that. Story closed, apparently. This was a little over a month ago.

Then, a few days ago, it started again, on the KOffice mailinglist. He said he heard on the KDE PIM/KMail mailinglist there would be integration between KOffice and KMail. With integration, he apparently meant they would merge, which of course lead to a "huh?" from Boudewijn.

And again, I tried to explain how it would be unlikely KDE would integrate with just one application, but rather go for a common infrastructure. Then came the email I really wanted to let you guys read, as Kevin Krammer wrote such a beautiful response, pointing out the exact flaw in reasoning which made this discussion go on and on:

Basically a misconception based on the way applications aggregate functionality on uncooperative platforms such as Windows, i.e. by putting all in the same application.

Of course! And this other way of thinking and working seems pretty hard to understand. See how companies often have trouble separating "Freeware" with "Free Software". And even when they do, how hard it can be to play by the rules, or to cooperate with the larger community. See how users have trouble with the paradigma's in the FOSS world, like how installing and managing software work.

And of course, the central theme of FOSS is cooperation. It's what we do, breath, live (see what I stumbled upon yesterday, or how LWN.net currently has a story about Volkswagen working on the linux kernel - which you can't read yet, subscribers only). And apparently, it is hard to understand it's full implications, no matter how basic it is for human nature... Kevin on that again:

Obviously KDE applications, on any platform, can do better, i.e. using our framework's cooperation infrastructures and shared libraries.

So the idea/suggestion can be rephrased as "thing about using communication infrastructure", which I am pretty sure the KOffice developers are already thinking about for future releases, e.g. collaborative editing.

Topics such as this show how more advanced the KDE framework is. While other office projects have to basically swallow communication tools (probably a full blown PIM suite), KOffice has the option of just interfacing with the respective domain specialists' work.

Amen. The KDE, the Linux, the FOSS way of thinking is so much more advanced, many on the other platforms don't even get it when we try to explain it ;-)


I really hope and expect this to change. Over time, both users and companies will start to understand. And that will benefit FOSS enormously. It's about communication. Explaining how we think and work is incredibly important. Cooperation is so fundamental to how we think and work, even when we 'compete' with other projects, we don't even see it that much anymore. We don't get it when others don't get it, and try to explain the details instead of the big picture (like I did).

Love to ya all,


/Jos

performance 2

Now I got a few responses on my blog about performance in windows, so I thought let's add a few new irritations.

My university has recently build a really amazing new library. It's architecture is pretty stunning, imho. Of course, it was WAY over budget, but hey, spending a few million on great architecture - I'm not even that opposed to it. Though they cut all college hours by a few % to pay for it... Aaah well.

There are a lot of PC's in there. They use thin clients, win Xp... Big, 19" screens, nice keyboard and mouse. Feels like they choose the wrong resolution, though (non-native). I can't change it, the whole thing is locked down pretty heavy.

So. And how is the performance on those things? Well, it depends. Sometimes, the Start menu reacts in 2-3 seconds, but it can be minutes. It often takes me 3 minutes to start Calculator... It's very irregular, though. SPSS runs reasonably fast, at least when doing it's calculations. Yet, every time I middleclick a link in IE 7, it takes at least a minute before the new tab is opened.

Those of you with a lot of work to do and slow hardware know how frustrating this is.

Aaah, well, that gives some time to play...

Putsy!

This morning, we found blood on the chair and table next to my little lovely dwarf hamster Putsy's cage. Which of course scared the hell out of us.



Now Putsy proved to be allright, fluffy and lovely as ever. He now comfortably walks over me, and I can carry him around. You've got to be careful, though, as he doesn't understand heights at all - just walks around... Rather stupid, but hey, what'd you expect from an animal which fits in a toilet roll... :D


He really likes that transparent ball to run in, btw - he runs through the whole room. We where afraid he wouldn't like it, but as far as I can tell he's really into it - as soon as he can get into it, he will...



Edit: for those concerned (thanks), I forgot to mention we thought our cat got Putsy ;-)
We now figured it probably went the other way around and Kippy, our cat got hurt. We can't find any wound, but hey, furry animal...

Bugs

While making screenshots for my presentation, I found a few bugs. First in the file open/save dialog, where drag'n'drop to the bookmark bar on the left didn't work. Yes, DID not, Rafael Fernández López fixed it a few hours after my report ;-)

Now there's a weird problem in dolphin, which I stumbled upon while I was making a screencast - the Columns view doesn't work properly with Split screen mode - see the Youtube video:



As there's a huge bugfixing and coding frenzy going on (do you guys ever sleep? I think there's an average of 100 commits/hour right now, been like that since yesterday). So I hope this gets fixed too. Rafael is already in contact with Trolltech about the "horizontal scrolling in Dolphin's Columns view goes with 1 pixel per scroll" issue. Boy, is that a busy guy :D

Anyway. If someone has a working Dolphin, I'd love to see a screencast like the one I made earlier - but then with Oxygen style, and also with some Columns view animations.
I can't get kde to compile right now - which makes sense with our Special Extra Extra Binary Incompatibility Day - but you know, I've got a presentation tomorrow and I want to show off some stuff ;-)

Back to the (too much) work I have...

So, those who hate NON-KDE things, and little, furry animals in particular: skip this post.

Because even though I've spend half the day on KDE, I don't have much to say about that. I do however have something else to tell - today, we (my ex-GF who I still live with, and me) welcomed two new additions to our household: Xina, the rat, and Putsy, the dwarfhamster.

And boy, are they cute. Xina is really the loveliest rat who ever climbed all over me - she is extremely curious, even though she is 1,5 year already. And of course, there is Putsy. Well, see the pictures and judge for yourself...

Xina looking at us...

Xina exploringXina on the lookout

Exploring the new living space...candy is nice, yet she prefers to be in the tube

So I'll desperately try to bond with her in there ;-)

Aren't they cute? It's hard to make good pictures, I'm not that good with a camara, and they never sit still... :D

Performance - Win & KDE

People often say Linux has a better performance than Windows. Others disagree, and say the opposite is true. Now in my own experience, it's mostly so that both perform differently. windows boots up faster, in the sense of showing the desktop. But you can't actually USE that desktop, clicking the start menu as soon as it's show can take several minutes. In linux/KDE, it'll show slower if your session is still being restored (that functionality doesn't even exist in Windows) but it won't take minutes.

On the other hand, moving and resizing windows goes faster than in Linux. And have you ever seen your mouse anything else but smooth in Windows? I can stop my mouse for a second even on my 2 ghz/3GB dualcore system in linux - just use konsole with 10 tabs, set it to send the commands to each tab and log in as another user (10 times). That's not even hard - but X chokes on it.

Yet I've changed my opinion in the last few months. I've worked with windows a lot, and the deficiencies are becoming clear. Sure, drawing performance is excellent, and the mouse never stops. But start firefox (and let it restore 5 tabs) and your system becomes unusable for a few seconds (not the least because you just can't minimize the starting firefox, it insists on jumping up and taking focus a few times). It takes 10 minutes at least to boot up and start Outlook and firefox. Pretty painful. But the weirdest thing is that the system can become very slow without any apparent reason. The start menu normally takes it's time for showing submenu's, but sometimes I'll have to wait over a minute; the background doesn't redraw, I can't switch windows. My collegues react pretty dull to these kind of things: "you're trying too much, just wait". Well, I got work to do, I don't want to wait.

So I tried to figure out what's wrong. In linux, I use a cpu meter on my panel. That way, you know what's going on - is an app slow, it's because you're compiling, moron!

But the CPU monitoring stuff on windows is entirely useless. Really, wtf is that thing measuring? It seems like some random value... For example. The following screenshot was made a little over 10 minutes after boot. I started firefox, an explorer window (never showed up) and Outlook. So everything stopped to redraw, most things got slow (but not moving mouse, or even a window). So - there must be something going on, right? Well, no. According to the system monitor, those apps which didn't start nor redraw didn't stop working due to a lack of CPU or memory:

(screenshot taken after minutes of waiting for a response - thought the system was busy...)

As I know a little of scheduler things on linux (having followed the -ck mailinglist for years) I suspect a priority inversion or something like that - an higher priority process wants data from a lower prio process, but by being high prio, it makes the low-prio one unable to actually process and send the data. This seems to happen a lot, and most Windows users here at work are so used to it, they don't even notice it anymore. Not being able to work for up to a minute, many times a day - apparently, you can get used to anything. Boy, I get annoyed if the K-menu takes more than half a second to come up.

Guess there's a good reason why Vista takes up so much resources - these hickups of course seem to be smaller on much stronger hardware. Stronger hardware = more room to fuck up. So instead of fixing the scheduler (and other) problems, they up the minimum requirement... Gotta love those guys.


How much money would companies earn on switching to linux? I mean, JUST decent windowmanagement in windows, I'd spend a million bucks on that if I had it. Windows just take focus while you're working, or they seem to have focus but don't (Outlook asks for my pasword everytime it starts. It shows a little 'type pasword here' window, which seems to have focus, but doesn't). And don't get me started on the alt-tab behaviour - even a tooltip over a button seems to count as a full window in alt-tab, so you can't use that to switch to another application if your mouse is over a button!!! blegh. I don't understand why ppl take that pathetic excuse of an OS seriously, and say 'linux isn't ready for the desktop'. No, WINDOWS isn't ready. Linux was ready years ago, but MS still has a long way to go. The only reason it's being used is because ppl gave up on it - they don't try things more efficiently (alt-tab) because it won't work. Just do everything the slow and painful way. Companies should sue MS for RSI...

videos are cool

As I gotta give a talk about KDE 4 in about two weeks, I thought about preparing a little. I'd like to make it as visual as possible, as I'm not such a technical person. So screenshots. But what about screencasts? I can make a screencast me, right? Sure, not even hard. So I present you a screencast of Dolphin, showing off the smooth animations in KDE 4 (not so smooth in the video).

Yes, it uses the plastik style. I'm sorry. But Oxygen is right now so seriously broken, I didn't have a choice. The next screencast will have Oxygen OR Bespin, a cool, configurable and flexible new KDE 4 style. (Bespin is what Oxygen used to be before Akademy, so it's heavily inspired on the first Oxygen mockups, but very configurable - which makes sense as it's written by the author of Baghira!!!)

---> above was written a little over a week ago.

I wanted to re-do the video, but I made a mistake in making a youtube account - I used another email adress than the one here, so I can't couple my blogger account and youtube. Removed the youtube account - but my name is still used :(

So I planned to blog only about this when I figured out how to solve this, and keep this blog as a draft.

Then I found my video. Yes, stumbled upon it. apparently, it wasn't removed with my account (?) and even got quite a few viewers. Aaah well. So lets post this anyway.

Here's the video.

KDE Beta 3 is coming!!!

Dear people, friends & fellow gearheads,

There's a new Beta coming. Still over a week to go - it will be tagged October 3th and released one week later. But last time we started writing the announcement a week before it's official release (shortly after tagging) and we had a delay of one day (and some stressful days for the promo ppl).

I'm not a big fan of being late. So, I started writing the announcement and overview of what's new on September 18th already. That should do it.

And I think now is the time to start asking for great stuff, features, things which should be mentioned. It's all most tagging time, so not much cool will get in Beta 3. So, everyone who wrote, read or heard about or just saw some cool feature - put it on the announcement page.

Don't be afraid to put things there which might not be important, or things that might have been from before beta 3 - I'll check, I'll write. Links to blogs or just a commit are highly appreciated, though, as it makes the above much easier. And no, you don't have to be a developer to do this! Anyone who occasionally reads the dot, or follows some mailinglists, or the planet, hangs out on IRC - all of you who know something about the development can contribute here. Look at the page, see if something is missing, and if it is, just add it. And if you feel like it, yes, you can write something more elaborate.

It's easy, it helps KDE. So why not?

KDE-Edu

There was an email today about the KDE4-Edu-polishingday-story from their 'master' (I was almost gonna say mother. Should I?), Anne-marie Mahfouf. She responded to a little discussion about how polished Ubuntu was (or rather, was not) according to Walt Mossberg, some Wall Street Journal writer. The Edu polishing day was very successful, despite all the negative comments on the dot-story. And these developers receive more negative comments, it's not just there on the dot.

PPL don't seem to realize how valuable KDE-Edu is. And they still don't seem to understand how FOSS works. Let's just hope the first can be fixed, and the latter is due to all the new ppl we have in our community, who simply haven't learned the ropes yet. I won't go into the "How does FOSS work", as that apparently can't really be explained, one has to see how a community works and decides how and where to put resources. It just takes time.

But I can talk about the importance of KDE-Edu. And I don't even know where to begin. One might say: "I don't use those applications". Sure. I don't. So that's it? We're just gonna go "If I don't use it, let's stop working on it"? There are millions of children out there who would be (and are) very happy with these apps. Have you ever seen how bad, how incredibly bad most educational applications in schools are? KDE-Edu is ahead of what most schools pay thousands of dollars for, really. It's a driving force for KDE in schools, you know. I actually have an article in the pipeline about that, a company which makes it's mony mostly by bringing Linux/KDE into schools.

But that's not all. KDE-Edu is generally ahead of the rest of KDE. The usage of GHNS2, SVG (!pixmap cache!) and other core parts of KDE in Edu leads to loads of bug fixes and better functionality which benefits everyone in this ecosystem. Marble, anyone?

Also, the KDE-Edu part of our community is very friendly to newcomers. Yes, we all are. Of course, we're all big loving hunks'o'love. But it's rather daunting to work on Konqueror, you know. It's much easier to work on Khangman. That's what I'm talking about. If you want to learn KDE development, it's easier to start in the KDE-Edu project. And these people have a lot of experience with newcomers, as they simply HAVE a lot new ppl all the time. So, there you learn how the community works, you learn how to work with C++, Qt and KDE code, how to use the KDE infrastructure and what code styles are acceptable. In time, you can probably work on other parts of KDE. Big win-win, right?

And last something I know a little about.

• Do you know which apps have been most prominent in the KDE 4 presentations I gave the last 2 years?
• Do you know which apps always have been the best looking out there, during KDE 4 development?
• Do you know which apps where run at booths to show people what KDE 4 could do?
  
• Do you know which apps ensured people where like "wow, KDE 4 looks cool" and "hey, it's not all vaporware"?

Yeah, those apps which looked the most polished and stable, which really showed of the new KDE 4 capabilities. KDE-Edu and the KDE games. Promotion-wise speaking, those have been on the forefront, pulling our efforts to a higher level. Without them, I would've been without nice screenshots on FOSDEM, 2006. To give just one example of a meeting where I really would have hated to be without KDE-Edu and KDE-Games. Because EVERY other KDE app still looked like sh*t back then.

Really, KDE-Edu is one of those parts of KDE you CAN NOT IGNORE. Even Edubuntu, a project not exactly pro-KDE (once in a time they wanted to rewrite Kalzium in GTK) is forced to rely mostly on KDE-applications - just because they are the best.

So please, give this part of KDE the respect it deserves. Every part of KDE matters, and they have done an amazing job. I think, after all this flaming and negativity, it is time for three cheers for this Very Important KDE project and their developers.

edit: and here you go.

KDE apps on Windows

Now everyone knows KDE apps will be usable on windows. Recently, KDE-nl'er Niels van Mourik send me an email with some cool screenshots with KDE apps he compiled on windows! So, I thought that'd be worth posting here.































































Thanks, Niels, I'm gonna use these for presentations...