TL;DR, I’ll be switching to releasing new wallpapers every second Plasma release, on even-numbered versions.
This is just a post to refer to for those who have asked me about Plasma 5.15 and a new wallpaper. Since I started working on Plasma 5 wallpapers, there has always been a number of factors determining how exactly I made them. After some agonising debate I’ve decided to slow the wallpaper release pace, because as time has gone on a number of things have changed since I started contributing them:
Bugs & Releases. One of the early goals for wallpapers was to have one for each release so developers could identify versions of Plasma in screenshots of bug reports. This has become far less important, as issues have gone from “the bug causing everyone’s machines to catch fire while eating kittens” to things like “maybe stealing your left sock from the dryer”. Back in the day most distros didn’t offer rolling release options, so users would be reporting the bugs and sharing screenshots of old buggy versions. That, too, has changed; not only are rolling release options more plentiful, but standard release distros are well passed the dark days of immature Plasma 5. All said and done, we just don’t need wallpapers for developers to identify problem releases anymore; the bugs are far less severe and people are more up-to-date.
LTS Plasma versions & quality. While it may seem irrelevant to wallpapers, LTS stands out to as the place where we really need to pour love and care into our designs. With each new wallpaper I’m pushing things a bit harder and a bit further which means taking more time to create them, and I’m realising that at the quality I want to drive out LTS wallpapers with, it might take 3 to 5 dedicated days to produce a final product. That’s not including post-reveal tweaks I do after receiving feedback, or the wallpapers I discard during the creation process (for each wallpaper released, it’s likely I got halfway through 2 other designs). In other words, it’s becoming less sustainable.
The wallpapers aren’t crap anymore. It’s no secret, my first wallpapers were rough. When a new wallpaper was finished there were real quality incentives for me to take the lessons learned and turn-around a better wallpaper. Nowadays though most new wallpapers are visually pleasing and people don’t mind if they stick around for a bit longer. I know a lot of people even go back to previous wallpapers. Adding to this, it’s gotten easy to get older wallpapers; OpenDesktop, GetHotNewStuff both serve as easy access, and we now have some of the most popular default wallpapers in the extended wallpapers package. While new wallpapers are always nice to have, it’s no longer bad to keep what we’ve got.
Between those big three points, it brings me to moving the wallpaper cycle to every second Plasma release. New wallpapers will fall on even-numbered Plasma releases, landing squarely on the LTS releases and a feature release directly between LTS’s. That being said I hope that future wallpapers will show quality reflecting what the additional time will afford me to do.
After posting the Plasma 5.14 “Cluster” wallpaper and asking for feedback there was a huge response, and after a few days of big changes and finer adjustments I hope this will serve as a satisfactory wallpaper. I’d like to thank everyone who offered constructive feedback, pitched in ideas, and even offered examples, you’re amazing!
Cluster and the source SVG file are now available on OpenDesktop and the KDE Store. For those seeking the Krita source file, please contact me directly and I will ensure it’s available somewhere.
The time for a new Plasma wallpaper is here, so for 5.14 I’m excited to offer up “Cluster”.
But first, please allow me to gush for a moment. In tandem with Inkscape, this is the first wallpaper for KDE produced using the ever excellent Krita. For graphic design my computer has a bit of beef to it, but when I work with Inkscape or GIMP things always chug just a bit more than I feel they should. Whenever I’ve had the distinct pleasure of opening Krita, even on my lesser powered laptop, it’s always been productive, rewarding, and performant. I’m looking forward to using Krita more in future wallpapers. *claps for Krita*
Now, with pixmaps there’s always a valid concern that higher-resolution monitors will suffer blurring because of low native resolutions. The master file for this slightly larger than 8k, so hopefully this will not be an issue. The only potential problem this causes is the large size of the master files. The Inkscape source will be published when the final wallpaper is released as per usual (just under 50MB), but the Krita-based assets are only going to be available on request. This is because the .kra is 135MB, and I have a feeling a few people might be angry if I load that onto the shared server. Unless they read this and tell me it’s fine. Who knows!
It’s been too long since I’ve posted on Planet… I missed you! But despite my slothish activity there are rituals to be followed, and so comes a wallpaper for Plasma 5.8;
Probably the first thing I’ll mention is that the Plasma 5.8 wallpaper will be shipping with a 4K UHD version. The last wallpaper was meant to have a 4K version, but it simply didn’t happen. Seemingly everyone is beginning to enjoy screens with high pixel densities, so it’s about time we shipped wallpapers to match, and it’s a fun bullet-point for an LTS release.
Here it is;
We still have a short window for tweaks and adjustments, so if there’s feedback for minor changes I can try to fit them in. I know a couple minor tweaks I’d like to make as well.
The general theme of the wallpaper is to try bringing back the vibrancy of earlier wallpapers; there’s been a trend making things progressively darker, and it had been mentioned that several people missed the energy of older wallpapers. With that in mind, hopefully this iteration has that light and energetic vibe without looking like a hot mess.
…
On a more personal note, some weeks ago the company I work for had been bought out. Because of that everything I was working on had to be put to the backburner while I sorted things out. I had to make some extremely difficult decisions, and I’d be lying if I said it didn’t mess me up for a while there. It’s been intense. I also still have i’s to dot and t’s to cross.
Ultimately it means that I’ll be moving from coast-to-coast and south of the border to work in the United States. It’s a bit freaky penetrating the bureaucratic nightmare that is immigration forms, and sobering as I send them out. But I’ll be joining the ranks of many great Canadians who crossed the border: Jim Carry, William Shatner, Mike Meyers… *cough*Beiber*cough*
I can’t say I know what this will do to my contributions; whether or not my new job will give me more time, less time, or if I’ll need to stay back until I even really know 100% what’s going on. I certainly don’t plan to stop contributing, but I can’t say how active I’ll be in the near future until I see where the chips fall, things are also still in a state of upheaval.
I am, however, still looking forward to Akademy. I’m set to give a 30-minute talk on design iteration; whether or not you are creating a new application or maintaining an old beast, effective iteration is the key to great design. 😉
With Plasma 5.6 long out the door, it’s time for the traditional changing of the wallpapers! Or at least, showing what the next wallpaper will be.
With Plasma 5.7 we won’t be venturing too far from where we are in 5.6. As I mentioned in a previous post about wallpapers we have been paying attention to the feedback, trying to find something that hit the right balance. The 5.6 the wallpaper seemed to hit that mark, so you’ll see fewer dramatic swings in the wallpaper direction; we’re goanna stick with what works for a while.
I’m keeping very close to the formula of the current wallpaper, and generally this is what people should expect for a few wallpapers for the next few releases of Plasma. I’ll vary the ‘material’ and positions a bit in the future, but I didn’t want to do that too much during our transition to perspective this release… Perspective was the one thing I meant to do with the current wallpaper, but for various reasons it didn’t happen.
One thing that also came up was assembling the old wallpapers somewhere for the people who preferred a previous release. I’d like some opinions and feedback on a few questions if we decide to do this;
Where would you want all the wallpapers stored? A ‘legacy wallpapers’ package, the current additional wallpapers package, OpenDesktop?
Would you want me to “George Lucas” some of the wallpapers, and tweak/improve the lower-quality ones for re-release? Or should we just drop some of the really early ones?
So, what do you think we should do with the older wallpapers? Comment below, let us know!
For those who haven’t seen it already, I’m very pleased to announce that I’ve been working with Michael Larabel over at Phoronix to post an in-depth review of Plasma 5.5.
I gotta hand it to every KDE contributor; I call this review comprehensive but there’s an incredible amount of information I could not cover in a sane article, and it could have easily been twice that length while still failing to hit every feature.
From me to everyone; you’ve all been knocking it out of the park, great work, and thank you. I’m looking forward to what the KDE community brings in 2016!
With Halloween settling down and children retreating back to their lairs so they can bathe in their sugary loot, it’s time to post an update, and not just any type of post – but a Spooky Scary Post-Halloween Monster Post!
Wallpapers
Before I get to show-and-tell I wanted to make a quick digression to something we noticed a few months ago after the 5.4 wallpaper was released…
There has always been some pretty harsh criticism against the wallpapers I’ve produced, some of this comes down to being bolder and more vibrant in our designs, and some of it some of it comes down to the fact that my early work was genuinely bad. We listen to comments wherever they come from (even if we don’t specifically reply), be it a forum on a news site, Reddit, or imageboards. Until Plasma 5.3 though the criticism lacked constructiveness and was mostly just mud-slinging. The Plasma 5.4 wallpaper though must have crossed a threshold at some point, because the entire VDG very specifically noticed an uptick in constructive criticism, and a it had a heavy influence on the 5.5 wallpaper.
What this all comes down to and what I really want to say is this; do be critical of our work! But be critical in a constructive way, so we can build on your comments. Calling a wallpaper “dogshit” doesn’t give us much to work with, but pointing out the Dutch Angle of the last wallpaper as being too extreme – that we can work with and improve the next wallpaper. Since we had the feedback, I’ll go over the two main points we’ve heard.
#1: The Brightness / Saturation.
More often worded as “the author must have eaten his crayons before puking on the screen” this was a result of how I initially imitated the 5.1 wallpaper with the Breeze palette, and absolutely failed; so much in fact that I think it may have affected the perceived colours of later wallpapers.
While some people certainly enjoyed the lighter wallpapers the main comment was that the over-saturated wallpapers were too much. Interestingly, wallpapers on Plasma 5 have been trending towards darker tones, below being some swatches I quickly composed of our wallpaper history:
When I started making the wallpapers at 5.2 I had decided to stick with the official Breeze colour palette, which is geared towards icons. This meant that working at the same luminosity Nuno used for the 5.1 wallpaper would oversaturate mine, which is what happened. It’s worth noting that the 5.2 wallpaper was made purely for personal use, and it was only by a fluke that we used it in production. With 5.4 I think we approached the tipping-point of appropriate brightness/saturation, and I think we’re closer to the ‘right’ amount now considering out palette.
#2: The Dutch Angle / Drug Induced Wallpaper This is a simple fix: stop using intense angles. But! If everything is made flat it becomes visually uninteresting. As a matter of fact none of the KDE wallpapers have been perfectly level, except Nunos original wallpaper which had clear vertical orientation. I think this was just because 5.4 was so extreme, and also because there were no other mounting points a user could visually register.
With the ‘acid trip’ feel of the last wallpaper, I think it was (again) the dutch angle throwing users off a bit along with the fisheye lens of the horizon line. I do worry that such a perception may impact the professionalism of the desktop, so for future wallpapers I may attempt to better avoid this moreso – though this wallpaper does maintain a more organic shape, which I expect may get dinged on that score.
So, what’s in the pipe for 5.5?
I’m very excited to announce we will be shipping 3 wallpapers this upcoming release. The two below continue the evolution seen in previous wallpapers. They are “Event Night” and “Event Day”. Event Night will be the 5.5 default.
Lionel Chauvins’ “Pastel Hills” will also be available, which harkens back to Nunos original design using a lighter pastel palette. I also have the feeling this is the first wallpaper we have distributed made with Blender. I highly recommend checking out his new KDE-look account if you like the smooth jazz that is his wallpaper, hopefully he uploads his other works. 😉
5.5 Wallpaper Contest Finally, Andreas is continuing his wallpaper contest; the deadline is in roughly 9 days, so if you have a beautiful image you want to submit please jump in and submit your wallpaper!
KDE.org
KDE.org is undergoing a redesign which should one day present a more unified and consistent interface across the myriad of systems we currently use.
The most obvious issues with the current site are twofold; there’s no consistent navigation, and no two systems look alike. Because we have so many systems which are largely incompatible and/or on completely different hardware, we’re taking a unique approach to the new design so we can begin to unify the disparate designs.
We’re building the user-facing elements as a modular set of pieces which can be arbitrarily inserted onto any website, regardless of the technology or hardware they use, as long as they support even the most primitive skinning. These modular pieces are self-contained, and should be fairly easy to insert into existing systems until larger changes can be made.
I’ll have screenshots later (maybe a video) once I finish up a few more modules for feedback. Unfortunately I’ve had exceptionally busy weekends (when I get most of my work done) and haven’t been able to make the progress I had hoped for. I’ll post more on that later.
Fiber Browser
Because I have been swamped with smaller projects I’m temporarily going to put Fiber on hold to nail other things down, as I want to give more time to immediate smaller impacting projects across KDE as a whole, rather than constantly scrambling around several half-finished todos.
The original plan was to have a version which would be “presentable” at Sprints so I could garner interest, but that will be dropped. One thing that has become clear is that other developers will want to work on it regardless of me ‘promoting’ it, so I’m comfortable in the thought that I could assemble a small team later on. Also, the main KDE devs are busy enough anyway.
Next, after (very careful) consideration I may temporarily drop CEF and pick up WebEngine when I seriously resume the project. Fiber is a one-man band, and to say CEF integration has been nothing short of a pain would be an understatement. I feel like the most important aspect of Fiber will be a rich, deep API and modular design – but with so much focus on getting CEF functional it simply sucks the life out of the entire project. Instead, I may shift to a CEF port as a “Fiber 2.0” feature (hopefully when other devs may maintain the APIs), which should help as by then Servo will be more mature and I can test it as the primary renderer.
Unofficially I may still chip away at it – but for now I’m more comfortable saying it’s on pause while I focus on my todo list. I will resume work on it once I’ve bumped off a few smaller things, and hopefully It’ll speed up development a bit by switching to WebEngine for the 1.0 release along with having fewer balls to juggle.
Polish Effort
Before I say anything else, hats off to Hugo for his work. I’m not going to lie: I threw him to the wolves on this one (unintentionally!), and he’s solo’d the real work going into Breeze polish. So, hats off to Hugo for being blazingly awesome!
On the design notes, one thing that became apparent somewhat quickly was the fact that the design I presented began to heavily diverge from the current Breeze design, so much as to be considered a different design entirely. I’m still debating how to handle this, as this is one area where I wanted to free up time so I could more properly contribute.
In terms of stuff getting done, we’ll have some pleasing adjustments to several visual elements such as menus and pixel-tweaks. We’ve also identified several issues such as misalignments in applications, dark-theme colour woes, and inconsistent spacing; I don’t believe we have fixes in for everything, but I’m confident in my ability at throwing Hugo to the wolves. ;P
DWD
There’s not much to report here, but a couple people have been wondering about this. For those not in the know, DWD will be a protocol-driven solution for widgets in the titlebar, similar to the CSD approach that is the Gnome headerbar.
Mainly I’ve been working on the specification, and it’s been pointed out that DWD as a technology will never be suited for insanely weird and creative widgets. To mitigate this I had written some crazy crap about all the special and unique ways a widgets might be customised, and I realised it was pointless to try matching the “creative potential” of CSDs with endless options. I did a thought experiment and swung the other direction;
What if instead of offering primitive widgets with crazy tweaks DWD focused on higher-level but rigid purpose-driven widgets? You don’t request a slider with a volume icon, you request a volume widget and feed it a few channels. Instead of a lineedit you’d just put up a search box… And this approach shaped up surprisingly well.
The general mindset is the idea that CSD eschews system integration in exchange for more radical customisation. DWD on the other hand is about integration though standards – and the initial spec didn’t play to that strength. The main downside to this new spec is the fact that we do sacrifice more creativity in the headerbar, but I looked at it, and in most screenshots of Gnome CSD widgets seem remarkably standardised as well. I’ll be doing a post later which gets into details and pretty pictures but this seems to be the direction to move towards.
Just over 2 weeks ago I stepped off a plane, putting my heels onto Canadian soil after spending a week participating in the Plasma 2015 Sprint. The entire experience was exhausting in the best of ways, and after landing home my throughput was thoroughly trounced for some time as I settled back into normalcy. But lets rewind to the beginning;
The day of my arrival in Barcelona it would be a far cry to say I was nervous – in the moments before pressing the buzzer I was in a downright terror! These people will realise I’m an idiot! Ship me back to Canada on the next canoe! Needless to say only minutes in to the sprint not only were my worst fears completely unfounded – but I met a group as welcoming as they were brilliant.
Finally, I think I have the perspective to share my experience. I won’t try to recap the entire event, I will mainly focus on VDG work.
But first! The People of KDE
I met about a dozen dedicated and hard-working developers in the Blue Systems office during the sprint, and it needs to be said just how great these people are – each and every one passionate about their respective fields and projects. I’d really just like to give a shout-out to everyone I met in the Sprint. They’re the kind of people who make you smarter by proximity, and they welcome you to do it. For anyone invited to a Sprint I highly recommend jumping on the chance; you will be enriched for doing it.
Drawing Konquis
After arriving mid-day Jens Reuterberg headed the idea to begin creating and stockpiling promotional graphics. Essentially we wanted vector artwork which could be used easily for things like release announcements, large print materials, web pages, etc. Jens dove head-first into logotypes, and I splintered off into doing up a pair of vector Katie and Konqui graphics during my half-day; Konqui being a direct trace, and Katie being new. You can view the original graphics by the talented Tyson Tan here.
There was a great deal discussed during a pair of review and planning sessions in the first two official Sprint days. One of the biggest things (for Jens and I) was helping the VDG and developers interoperate better; for those who don’t know, the VDG communicates very differently than mainline developers.
Devs tend to focus on bug reports, mailing lists, reviewboards, and IRC. Members of the VDG tend to use Forums, Hangouts, and to a limited extent IRC. Immediately there’s very little overlap, which means at this point developers have to go to the forums to wield the VDG.
The problem lies in how forums operate; where the VDG design processes benefits from the relative chaos, it’s not good for developers looking for the ‘final word’ of the design discussion. It’s further impacted by forum conversations which don’t have definitive conclusions, or discussions which can get muddled down. When developers go to the forums they need a solid final product to build around – but on multiple occasions they end with a half dozen different designs and no clear answer on what they should do.
It was a short discussion during the Sprint, but Jens and I both immediately agreed that this is an area where the VDG must step up and refine our process.
The current idea will be sticking with the forums threads as the main creative area, but changing the way they spin down. Once we feel a design discussion has gestated, the VDG aims to have a member pull the ‘final’ design from the conversation, at which point they’ll put together a coherent deliverable developers can understand and act on, on a channel they are comfortable with.
There are still details we are ferreting out before we more formally put this into motion, but the essential aim is to move the VDG into a position where we can reliably ship usable deliverable design, on a channel developers can comfortably handle.
Breeze Applications
This only came up briefly during the Sprint as well, but is something which has been brewing for a while now – so it might be worth mentioning ‘for realsies’, essentially since I don’t think anyone pointed out that this is a ‘thing’;
KDE and Plasma have a bit of a history with names, and for many core applications we’ve been wanting a more consistent scheme for it all. At the same time, with every major tookit release (i.e. Qt4 -> Qt5) many applications need to be ported or re-written. Finally, on these major releases, visual/workflow trends have usually shifted meaning the experience of applications will also shift.
So, all this stuff going on, we figure it’s time to put a bow on it and turn this cavalcade of factors into one cohesive event, so we’ve come up with the concept of Breeze Applications.
The idea is that, coinciding with frameworks, trend, and design changes we will name a subset of the bundled applications after the current design. So for Plasma 5 we will have ‘Breeze’, for some future plasma version many moons from now we may have ‘Gust’ or ‘Wind’ applications.
What does this mean? The biggest thing is that we intend to use these ‘Breeze’ applications as standards bearers, which we hope to see other applications follow. It’s much the same way Google treats ‘Holo’ and ‘Material’, along with their base applications: This is the design, these are the examples. Ideally we intend to focus on only a few applications, which developers will be able to dissect and say ‘oh, this is the plan’. In addition, as new technologies and techniques land, we hope Breeze applications will be the frontrunners in adopting cutting-edge KDE/Plasma technologies.
Does this mean every Plasma or KF5 app will be named “Breeze X”? No. We only plan on Breeze-ifying the more simple core applications which can be easily maintained, kept up to date, and streamlined enough that the code could easily be used for reference material.
Fun fact: The bathrooms in Frankford are powered by Ubuntu!
Dynamic Window Decorations
Before I even get started on this, I must give props to David Edmonston. The man is a trooper, and I feel almost as if I tortured the poor gentleman throughout the sprint.
During the sprint I presented some of my DWD plans; technical details were discussed, implementation questions were raised, and concerns were were round-tabled. The discussion was extremely positive and productive, and real issues were ferreted out.
One of the larger questions was ‘what IPC protocol should be used?’; I personally was educated about the Wayland protocol, and that it could be used even on ‘non-wayland’ systems – since it is just a protocol and not an installed library. Ultimately, the developers present agreed that D-Bus was the way to go, the general consensus being that the protocol is known and familiar, mature, battle-tested, and isn’t going to shift or break.
I also gave my personal thoughts on how applications might access/implement DWDs, and while there’s still considerable room for discussion, it seems to be on the right track. I was cautioned by developers and I feel the need to point out: even when the DWD protocol does pick up steam it will still be years before it’s available in any meaningful way.
During the development portion of the Sprint I managed to rope David into doing some DWD work on a proof-of-concept level. Through his efforts we now have a much better idea of what obstacles we will face integrating widgets into server-side decorations, such as ensuring the draw code runs correctly/efficiently. He heroically managed to get window decorations to draw usable sliders, so we do know window decorations are capable of drawing server-side widgets.
Sadly, the proof did nearly cost David his sanity. It probably didn’t help that I was giggling like an imbecile. Sorry about that, David. I hope the tea made up for it.
UI Feedback
Throughout the Sprint Jens and I were able to lend our services in helping to design and streamline interfaces. Towards he end of the Sprint we also did a walkthrough of the Plasma desktop and several components to identify surface-level bugs and weak areas.
This included an extensive review of the system settings utility and its KCMS.
I also managed to chip in some light advice with a new power-manager tool, and an upcoming redesign of the Baloo settings manager with Vishesh Handa.
And a Great Deal more!
As I mentioned at the start of the post, and can only mention again; There were a lot of really great people at the Sprint – and all of them had their own projects, goals, plans, and feedback. It was really impressive to meet people who had such a deep understanding of KDE Frameworks and Plasma, able to talk about extremely complex technologies in detail over a coffee.
I, personally, learned a great deal from everyone. From being unable to compile a package to now comfortably hacking, simply rubbing shoulders with the outstanding individuals was absolutely my privilege.
There’s a great deal not in this post, but I imagine other posts will fill in the rest… So on a closing note I will say again; if you are ever invited to a Sprint, don’t hesitate to say yes – it’s an amazing experience which is beyond worth it!
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.
Ken Vermette 