KDE is one of the oldest open-source desktop projects which can be found today, and over the years it has established a rich history of highs and lows. During some points it has been the undisputed ruler of the desktop world, while other times it had fallen behind or faced hard trials.
A memory everything but forgotten, just over 6 years ago KDE tore itself apart in spectacular fashion to assemble itself anew. Brave users who wandered through the rubble and wreckage saw developers rebuild the KDE before their eyes, witnessing the birth of ‘Plasma Desktop’ and it’s sister project ‘KDE Development Platform’. It was universally understood that this twisted gnarled creature of a computing experience was both hideous yet full of potential, and over 5 years of refining Plasma it had struggled, crawled, hobbled, walked, run, and eventually mature into a fine desktop.
Despite becoming an accepted way of computing there has always been one nagging persistent issue with it all; KDE is old and the legacy it inherited was a knotted mess of a foundation, with over a decade of old code accumulating to encumber nearly every aspect of the system. Software could not be written to use KDE Development Platform without pulling in so much baggage, and like a bundle of cords or strings there was no chance of pulling one from the mess without receiving the entire ball of twisted tangles; even a simple media player could bring in nearly all the legacy materials, even when used outside the Plasma desktop.
KDE developers knew what had to be done and set into motion years ago a complicated, time-consuming, and challenging goal: “we must untie the knots”. With a looming Qt5 transition on the horizon (the underlying toolkit used by KDE) developers saw their opportunity to untangle the ball as they ported to the next Qt.
But there were fears, warranted fears, that this process would again lay waste and pervert the now solid Plasma Desktop, people fearing they would be forced to decide between their beloved systems with an expiry date, or a new era of painful unfinished instability. The developers had a different plan in mind; a silent revolution planned to pass silently with little fanfare, as the underpinning foundations are churned into a sleek and modular framework which could be as loved as the desktop which used it.
“We must untie the knots.”
That day has already come and passed; dubbed “KDE Frameworks 5” for the technology, and “Plasma 5” for the environment/applications, these technologies have been in circulation as technical demonstrations and alternatives for some months now. A combination of nervous anticipation and memories of being burned by the 4.0 releases lead all but the bravest to venture early and discover nothing nearly as painful as the transition between KDE 3 and Plasma. With KDE Plasma 5.2 being formally announced as the default environment of Kubuntu 15.04 due only months away, Frameworks 5 and Plasma have been recognised as maturing usable products – which means it’s time to take a serious look at what to expect when you turn it on for the first time.
For the sake of simplicity I will be referring to KDE Plasma Desktop as “Plasma 5.2”, KDE Frameworks 5.6 as “Frameworks 5”; most regular people don’t need to know the exact version of the frameworks, and this review will be focused on the experience of the Plasma 5.2 desktop as it feels today. Some parts of the Plasma 5.2 experience are holdovers from Plasma 4, but I will cover them all the same should new users wonder if the hand-me-downs of the previous generation desktop gel with the new experience. I won’t be covering most technical issues in this breakdown; there are several that I had, however I’m using Beta software on an Alpha operating system – technical issues are to be expected which won’t impact final releases.