Yesterday the KDE four Core meeting started. This means that there are now some 20 KDE main developers sitting together for 8 days with the necessary hardware support (read: icecream) and will concentrate on KDE 4 only for these days. The result is hopefully a kdebase which is really usable for other KDE 4 developers. I also hope that the main bugs keeping Plasma out at the moment of the svn will be solved in this meeting – I’m really looking forward to the first technical preview of Plasma and the other KDE 4 functions and frameworks.
To get a first impression about the meeting, check out some of the blog-posts about it. Additionally Aaron Seigo mentioned that he will try to post about it once a day – that would be awesome! And imagine how the weekly commit digest will look like after this week 😀
Speaking about KDE 4 core developing: Qt4, the base for KDE, was released in a new version: . Although this is just a technology preview this version has already been imported into the KDE 4 svn as qt-copy: Qt4.2 will be the ground on which KDE 4 will be build. One of the main reasons is that Qt4.2 comes with a huge bunch of changes. Some are: a new DBus class, which makes it possible to work together with DBus natively on Qt level – KDE does not have much to do to use DBus now! One feature I also like is that there is now a Qt function which monitors file and directory changes. I don’t know how this is realised (sounds a bit like inotify), but that makes collaborate working between different applications easier (I guess). Also we will see the already mentioned GraphicsView in Qt 4.2 now.
That also means that KDE 4 will be build on the newest technique available in this sector. I pretty much like the idea that KDE 4 has this kind of company support.
Speaking about KDE 4 and company support, there is similar company support in another sector of KDE 4: the build system changed now over to CMake instead of continuing using autotools. The advantage is here (hopfully) that the build systems gets much, much easier and now usable even for developers who do not have any experience with build systems at all. Also the build support for other plattforms (MacOS, Windows) gets much better because this is all natively supported with CMake. The company support comes in this case from Kitware, and seems to be pretty strong: the Kitware developers even joined the KDE build list to help people.
I think these both examples show pretty well how company support can come to Open Source software: the fact that KDE 4 uses CMake and Qt brings these companies the advantage to see how there applications and libraries work in very big software projects. They see what is needed in reality, what is needed for such large deployments, what real life developers need and focus on in their daily live – but also which problems they see, which bugs come up, and so on. Additionally it is a kind of sponsoring: CMake and Trolltech (Qt) can both now point out that their stuff is used in KDE 4, using this as a impressive PR (well, suggesting that KDE 4 turns out to be impressive 😉 ).
Together with the now final build system and the final Qt version (although it is just a technology preview at the moment) KDE 4 will hopefully getting even more speed now. Let’s see how the core week goes on, and what the developers will report about it.