As most of those who read my blog have already heard, Qt5 is on its way. The target is 2012 and the focus is QtQuick where there is a high degree of separation between display and data and things are rendered using a hardware accelerated (read: OpenGL) scene graph. This is very much in line with where we are heading with Plasma as well. Exciting times!
What does this mean for KDE? Will there be a KDE5 in 2012 as well? What would a KDE5 look like? I know these are the questions on some of your minds, if only because some of you have already started asking myself and others about it. ;)
The short answer is that we don't know yet, but we're working on it. Not a very satisfying answer is it? Well, short answers are rarely much fun. So here's the slightly longer version.
Some of us have known for a while that Qt5 was brewing. The decision to start on libplasma2 that focused on QtQuick and moved away from all things QWidget was influenced by this knowledge. Thankfully, with Plasma's emphasis on Javascript, data/visualization divisions, use of OpenGL and more recently QML, we're in a good position to follow the Qt5 flow as it comes. We're already discussing on the mailing lists how to get involved and what issues will be most important to us. We're quite excited that Qt5 is going to be developed in the open, as this should give us much more influence in and foreknowledge of decisions that get made.
However, Plasma is not KDE, it's just one part of our rather large ecosystem of software projects and products. The biggest impact that a Qt5 will have is on the KDE Platform itself, since the library infrastructure relies on working well together as one cohesive unit. As Lars pointed out in his blog entry, the focus for Qt5 is to not disrupt the application developer by changing the API, but rather making performance oriented changes that result in the binary interface, or ABI, changing. For most applications, that will mean recompiles and possibly some source level tweaks here and there.
For some, however, it will be a little more drastic. Qt3Support will be gone, which means KDE3Support will almost certainly die along with it. If your application still relies on the Qt3- or KDE3Support libraries, this is a wake-up call to address that.
The current plans for Qt5 mean that, unlike Qt4's reinvent the world approach (which was needed, if painful), it will be evolutionary and far less disruptive. This is the good news.
I also see this as an opportunity for KDE's own libraries and runtime that form the KDE Platform. We don't need another big re-engineering of the base technologies as we had in KDE4, but there is a lot of opportunity to improve how the pieces fit together. Since Qt will be breaking ABI, KDE's own libraries will also have a new, binary-incompatible signature when compiled against Qt5. That means we have the opportunity to clean up things that require breaking binary compatibility.
Often this doesn't require affecting source compatibility. For instance, the other day in the libplasma2 branch I removed a data member in a public class that shouldn't have been there in the first place. This is binary incompatible, but doesn't matter one bit from a source compatibility perspective.
Some changes will likely affect source compatibility, however. KDE's UI and KIO libraries both need some hard changes made to them. libkdeui will need to split out platform, QWidget and generic components. KIO needs a similar split between platform bits, QWidget-centric UI and business logic bits. We need to think about how to reform the KDE Platform so that it is not only possible but easy to create builds for devices with less storage or targets where QWidget simply won't exist in the future.
The best news is that in just a few weeks, dozens of KDE developers are coming together in Randa, Switzerland to work on these issues at the Platform 11 meeting. The organization for this meeting actually started towards the end of last year, and the timing really couldn't have been better.
Today we stand with a bright future ahead of us, with Qt growing leaner and more modern and appearing on more computers and more devices every day, but we also stand with a number of open questions. We don't really know the details of what KDE Platform 5's libraries will look like. We do know it will be an evolutionary release, much like the transition from KDE2 to KDE3 was, with significant improvements. We will be grappling with those unknowns in the Alps, well away from distractions and surrounded by natural beauty, and we will start to draft those answers. A couple of months later we'll be in Berlin to come together at the Desktop Summit and push it yet further forward. We should, by then, have some very clear ideas of what the next year of development towards Qt5 and an eventual KDE5 will entail.
Personally, I can't wait. Perhaps because I remember how KDE3 polished the raw materials of KDE2 into a high gloss finish and can see the same patterns emerging here again. :)
