The Plasma team has no intention, desire or need to start "from scratch" nor engage in a massive redesign of the existing netbook or desktop shells.
One of the goals of Plasma from the start was to design a framework which would enable us to preserve work in the future. I was at the time quite disheartened that the design of kicker was so inflexible that, as good as it was, to make any sort of real changes to it would essentially require a rewrite of the whole thing. Even if it had been done piece by piece, at the end of a long development process there would have been no original code left. I went through the code and marked it up by hand to discover this. Keeping in mind that Kicker and KDesktop themselves were rewrites I was shocked, and so set out to create something that was flexible enough and free of internal assumptions so that we'd not have to "start over" again.
Fast forward to today and we have a robust framework with very few internal assumptions about what a primary user interface looks like. That's why we can use it for a desktop, for a netbook, for a tablet, for application dashboards and all the other projects people are building around it. Even as Qt has jostled about we've managed to keep Plasma bits coherent and avoided rewrites. Code that hasn't been touched in a couple of years in plugins and the shells themselves still works just as it did, and more importantly when we wish to add to that code it isn't difficult or time intensive.
Also keep in mind that Qt5 is set to be a "non-disruptive" release. It is mostly about cleaning up performance issues, focusing on QtQuick and improving the modularity of Qt. This will end up affecting binary compatibility, but source compatibility will remain largely in tact, especially for modules considered 'done' like QWidget based things. That means we are not compelled out of necessity to rewrite fundamental bits of our apps as we were with Qt4.
I expect there to be work to be done in the build system to reflect however Qt ends up being broken up into modules as well as a lot of work in managing the new QML2 and QScript work, something we've already started preparing for in Plasma. Otherwise, things shouldn't be too disruptive and I'm really looking forward to some of the performance improvements that will result from the Qt hackers really going "full steam ahead" on making Qt even more lean and mean than it is now.
One more important thing to consider is this:
This isn't going to happen tomorrow, or even this year.
Qt5 isn't scheduled until 2012. No release date has even been set. The release planning is still happening, but they've announced it this early so that we can all get involved. Qt being openly developed isn't just a story, it's a reality and Qt project management is putting their actions where their mouth has been. Bravo!
This means that a KDE Platform 5 can't happen any sooner than that. The earliest date that has been suggested thus far on the mailing list for a first KDE Platform 5 release has been January 2013, and even that may turn out to be "too quick". We'll see, but we have at least 2 more 4.x releases, and I would not be surprise at all if that turned into 3 or even 4 more.
As we cast our eyes out into the future by a couple of years, we are also keeping our minds on today and will continue working the 4.x code base. After all, it is what will become the 5.x code base. :)
I hope that puts some concerns to rest. As you can see, the KDE developers share pretty much all the same anxieties as you do about such a big release and are more than content to "just" deliver a more performant, more reliable, more featureful, more device-friendly version of our existing Platform and Workspaces. We've worked really hard to be able to say that, and will continue to work hard to take the next steps forward toward meeting those goals. :)

7 comments:
I look forward to see new releases, both in 4.x and 5.x branch. It looks very promising.
But...
What's your opinion about Qt Quick requiring OpenGL? I know that there is this CPU-based implementation from Mesa, but I wonder if it will somehow split the user base because Plasma Desktop (or the QML-using apps) will require too many resources...
On the other hand, I have good 3D acceleration on my GPU, and I can't wait to see the scenegraph-based QML and Wayland (specially if my wishful thinking becomes reality, and AMD releases fully open source drivers for their cards). I have mixed feelings. :)
Hello Aaron!
It's nice to hear about the fact that the development process is going to remain iterative. However, I'd like to ask you:with the Qt 5.0 release in a year, what is the situation with the proposed kdelibs (and other components) merge into Qt code-base?
I don't see the CPU-based implementation from Mesa being used AT ALL in the future...
All of Intel's chips now have 3D graphics processors built into them or require 3D graphics cards.. There's no exception...
Same thing is true on AMD's side starting the second half of this year, all their chips are going to have 3D graphics built into the CPU (AMD Fusion) or they're going to require 3D graphics cards (Bulldozer).. Again, there's really no exception...
Then on the tablet market, you've got the nVidia Tegra which isn't even x86 compatible, yet it's mostly a GPU with some ARM instructions bolted on.
So really, what's the point of CPU-based Mesa other than supporting really old hardware? Those people would likely want to upgrade for the 3D accelerations anyway, and if not, they'd no doubt prefer to run less graphics intensive desktops for performance reasons anyway..
@suy: "What's your opinion about Qt Quick requiring OpenGL?"
for most systems it's going to be excellent. the performance is simply not comparable (i've used it first hand :)
for other systems, we're hoping that a runtime switch to use QGraphicsView remains an option and then we don't need to absolutely rely on OpenGL.
if that doesn't end up happening (i've heard both versions of this story from people working on Qt ;) then we must make sure there is a reliable software OpenGL pipeline out there.
@ignat: "what is the situation with the proposed kdelibs (and other components) merge into Qt code-base?"
that's something we'll be discussing at Platform 11. there are no answers to this question right now, but it's one we'll be asking ourselves and working on next month in Randa.
@Sidicus: "So really, what's the point of CPU-based Mesa other than supporting really old hardware?"
tell that to the 50+ million student deployment in Brazil. reality is not always what we want.
and besides older hardware, there's the issue of the unfortunately all too frequent f/oss driver breakage. yes, the hardware might have it, but the driver may randomly puke on a given release.
it keeps happening, people keep saying, "that's got to be the last time, right?" and i keep saying, "I'll believe it when we go 3 years in a row without a mess."
hello Aaron,
Do you know which group in KDE does the UI design stuff, like the HIG standards etc. I think the kde-telepathy people are discussing UI aspects in mailing list but I feel they should be using the expertise of people who do such stuff regularly in KDE and have defined standards
sorry for offtopic message
>that's something we'll be discussing at Platform 11. there are no answers to this question right now, but it's one we'll be asking ourselves and working on next month in Randa.
Nice to hear!
However, I've just read a post called "Qt Components for desktop and started to wonder where this tech might lead us in terms of keeping our UIs consistent. KDE (and Linux in general) is known for being consistent, and we have lots of convenient standartized components in the KDE platform. Now people will get this awesome new tech and think, "Wow! How easy!" and voila, we have a new Windows Desktop Mess instead of KDE :D
And the second question, we have tons of wrapper code in the KDE apps. Quite a lot of code simply wraps stuff around. Look at, well, Digikam's code. And so on. Now this seems to be a mentality of KDE developers, no? What's the future of this approach? They won't have much code to wrap around with the switch to Qt5 and QtComponents, if it happens.
Post a Comment