Software vs. Philosophy; Raging against Microsoft as a Company is Backward

Today the FOSS world was shaken a bit with some of Microsofts announcements, mainly after the announcement of a cross-platform version Visual Studio which has a native Linux version. While not strictly their original brand-name IDE, it’s still a big announcement for Microsoft to put one of their top brands so ‘quintessentially Windows’ onto Linux… But the most interesting part of the announcement was not the release, but to me, it was the 3 distinct groups of onlookers who have been commenting on the news that the Redmond giant has quite boldly stepped far deeper into open-source wilds than it has been before.

The first group of people are the ones who have been supportive, praising our ‘enemy of old’ for moving away from lock-in and towards turning a new leaf; especially since it directly conflicts so completely with how they have historically monetised their business. Previously for Microsoft to win “everyone else had to lose”, but it has become apparent that this mindset is no longer in their DNA.

There’s the group of people who are looking at the software as what it is; a new development IDE which may be better or worse than contemporary Linux development applications. Some have noted it’s a fork of Atom, and while it disappoints some who wanted to think it would be a pure-MS codebase hitting the light of day – it’s still interesting to see Microsoft release products in the true nature of Open Source, where we fork software to make improvements we believe will serve it best.

But the group I’m most interested in addressing is the haters, the people who refer to Microsoft as “M$” and spit on any work the company produces. The people whose philosophical hate of yesteryears software giant continues unabated, their seething vocal loathing denouncing their work as the next plot or substandard because of its ‘capitalist origins’.

I’ll admit I went through a ‘zealot’ phase when I got into Linux – because I was young and stupid and half a hipster. The first year I thought I was awesome for ‘being free’ and ‘sticking it to the evil companies’ like Microsoft. I refused to use non-free drivers, and thought I was liberating myself by jacking-in my laptop because there wasn’t a free wireless driver. My setup was sub-optimal, and I was stupidly proud of my broken barely-functional equipment.

Today I find the functionality and flexibility of Linux suits my personal development habits, I find the desktop pleasingly functional, and I use software that works for me – regardless of the source. I use Steam because it enables me to entertained without rebooting my computer, with AAA-games such as Bioshock Infinite and Cities: Skylines running perfectly. I use the Xbox controller because extended play on any other input will hurt me. I appreciate that there are free alternatives which offer me a guarantee of ‘shenanigan-free’ computing, but where the software is good I will use it, even if it’s closed. If Microsoft releases products on Linux I may use them if they have a place – even if those applications are not free software.

When it comes to hating Microsoft, to me, that idea no longer makes sense. I will freely say I do hate and loath *parts* of the company, but to hate the whole umbrella regardless of the people involved is becoming backward. I love the teams who are saying “hey, lets get into open-source” while also raging against the legal arm attempting to leech from Android. It’s the same with Google; I love the parts of Google that sponsor open-source events while being wary of their disturbing advertising model.

You could argue that even if you only support the positive sections of a company the negatives benefit as well; that by supporting the Visual Studio team you’re potentially helping the slimy legal arm survive – but in reality if Microsoft sees support and benefits from better alternatives, they will shift their resources in that direction. A company that large requires time to turn the ship around, and there’s no real point in taking pot-shots at them when you can see their teams genuinely charting into such unfamiliar waters.

The fact is Microsoft isn’t a single hive-mind nest of businessmen looking to suck every dollar from the digital age. It’s thousands of upstanding people with real human problems who genuinely want to see the software they write improve the world. I don’t see cronies stepping onto public transit disturbing the bus driver because of their maniacal cackling – the world didn’t see an uptick in animal sacrifice and Hot Topic sales as Microsoft recruited its developers.

Am I going to use this new cross-platform Visual Studio? Probably not – I’m getting familiar with Qt Creator – but I will genuinely try it at some point.  For whatever reason the Redmond camp has become friendlier with open-source… Be it the fact that they aren’t the 800-pound gorilla, that Gates and Ballmer are no longer at the wheel, or because open systems are dominating new markets; it doesn’t matter. The company is improving its philosophy, and I think we’ll be the foolish ones if we dismiss it. If you’re a hater, hop onto the bandwagon of people paying attention to what they do – they’re publishing software in open waters, we’d be morons not to encourage, extend, and integrate.

Chroma Update

So, where’s Chroma, the experimental window decoration Breeze fork? Still not released yet.

The main hurdle is the fact that Chroma previously overwrote Breeze; once you installed the Chroma repo Breeze would be kicked out like a bad room mate.

Not having both is obviously no good. If Chroma breaks and crashes Kwin, it will restart and attempt to use Breeze, instead loading Chroma… And we get into a crash loop, require users to drop to a terminal, and install an alternate DE or window manager. Blegh. Ugly.

(Not that I believe it would do that, but if I did it to one person I’d feel super bad)

The cheap and obvious solution would be to just open my project directory and do a find->replace for ‘Breeze’ and replace it with ‘Chroma’, and I’m sure that would instantly resolve all the issues – but it would completely undermine my ability to easily pull/push back to the main codebase if I mangle it.


What I don’t want the Chroma codebase to be

Essentially, I want Chroma to read as Breeze in code, and I want both codebases to easily share between each-other without naming breaking things.

So, where are we?

Right now Chroma is installing, but there’s some quantum fiddly-bits which get all timey-wimey; when you install Chroma you are presented with two Breeze decorations in the KCM. Because I’m still inexperienced with this stuff, I’m still in the process of tracking down where I must rename Breeze to Chroma to get it registering properly, but I’m taking my time because I don’t want to rename things needlessly.

So right now it should be done ‘any time’, once I realise what minor tweaks need to be made so we can get Chroma and Breeze co-existing nicely. I’ll also admit currently Chroma isn’t my primary focus, so more/less I’m just taking the odd hour when I need a breather to browse through the code and see what needs to be done.

Cropping workloads and deciding what’s important

The FOSS community is amazing, and as often we may hear it has problems there’s one serious issue I’m sure we all agree with; we will always have a need for more contributors. Every project is starving for people – I couldn’t name a single project which isn’t on some level.

What we lack in fleshy human caffeine-to-output converters we make up for with passionate members, and the people who are part of projects are more often than not the insanely dedicated heros who churn enough work to equal more than a few of their peers. A huge number of insanely important projects are usually headed up by single individuals.

In FOSS you very quickly get noticed when you contribute, even if it’s a small contribution to a high-profile project. Once you get noticed other projects may ask for you, people who belong to multiple projects will ask to introduce you to other teams, and before long you realize you’ve gone from doing a couple projects well to several projects poorly. This presents a whole new problem I have recently come to terms with: You can’t contribute to every project.

I got all sour-apples about it with myself, one of those “you idiot!” inner monologues. Last week I said ‘yes’ to another project, and today I sat down and realised I was wasting peoples time. The person who invited me was catching me up, in the hangouts people were being patient while I straightened out my facts, and I contributed nothing. Using my crystal ball labelled “common sense” I divined that I’d probably only get an hour or two a week to offer up. Not nearly enough for the scale of that project, at least when you must budget time like a precious commodity.

In my seat I wrote out a list of projects I have on the go, and realised the number I produced was “too many”. I slumped, because I wanted to contribute to them all and I had to do the worst thing ever: start looking at projects to step back from. It sucked.

The problem with being attached to a project which you’re not really contributing to is that it can be a severe detriment to the people who are actively contributing; they may ask you to take care of a task, and what should have been a 2-day knockout turns into a 2-week slog, causing delays and problems.
So, I’ve stepped back from a handful of projects I had joined up with; No fears for anyone wondering if “you’re next”, since I’ve already sent out messages to the projects I’m stepping back from. Right now, I want to keep focus on at most 3 projects.

I’d rather do a few things well, than many things poorly. Hopefully, over the coming weeks, the projects I’m still involved with will see a stronger push from my end again, and adequate waves will be made.

Buzz Buzz!

With the Sprint behind us and the Freeze coming up next month, the VDG has made it’s agenda for the coming weeks, and I figured I’d share some highlights I’m working on, and a couple I’m personally looking forward to.



Andreas is doing a fantastic wallpaper contest which I hope many of you will participate in; the goal is to get wallpapers for weather-based wallpapers, and to also get several new wallpapers into circulation. It doesn’t have to be weather wallpapers – if you have a wonderful high-resolution graphic, submit it!

In addition to pulling in community work, we’re going to change up the release cycle for new wallpapers: Previously, wallpapers were updated every second version, but now we will add a new wallpaper for every release of Plasma!



The current crop of standard avatars have aged gracefully, but we’re looking to refresh them. We have a new crop of avatars based on history-changing individuals and fairy-tale children. Eventually we will expand the set to include a range of personalities.

Credit for the design goes to Jens Reutersberg who created the fantastic VDG profile pictures.



We may be looking forward to a new alternate decoration; originally based on Breeze and the result of a first-time hack gone too far, “Chroma” may be appearing! Somewhere! Where it shows up all depends on my laziness and incompetence. I assure you I am only mostly lazy and incompetent.

There’s a few things that need to be done with it, mostly in regards to properly breaking it out from Breeze to be it’s own decoration, and learning to properly submit it.


Several VDG members are looking to show up at Akademy, so if you’re looking to hear an awesome talk or two there will be some design talks in the future. I won’t go spoilertastic, but I’m looking forward to it, or dying trying to get there – you should be to!

Plasma Sprint 2015

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.


Download KatieDownload Konqui

VDG <3 Developers

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!

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!

I drank this. I still don't know what it was.

I drank this. I still don’t know what it was.

How Bread is Helping Make Breeze Cursors Pixel Perfect

Some people accuse me of being a crazy person. Others are wrong. But occasionally the seeming madness of it all will bring about good things.

Last night was a sleepless night in all the good ways; I’m excited for the upcoming Plasma Sprint, and knowing I’ll be packing myself into a cigar tube and flinging myself across the North Atlantic Ocean is too much for me to sleep over. I had promised a commenter (too long ago) I would make green cursors, so I decided to make good on my word. After it took 5 minutes I needed more; and the wafting smell of my bread maker inspired me to make a Bread cursor theme. Once that was done, sufficiently delirious, I sent my weird bready message to the VDG. They appear to have ignored it – a wise decision. They’re busy people doing actual work.


Today I opened up the cursors to see what I had done.  Nothing too terrible, and I decided it was worth polishing them up if just for the larfs. One of the touches was to add a half-pixel white outline between the crust and loaf for contrast.

When I rendered the tweaked cursors, they started to look awful because of how SVG images layer and clamp nearby vectors. Simply put on a vector edge, even if there’s another identical edge above it, both edges will affect their neighbouring pixels as opposed to the upper vector shape ‘blocking’ the lower shape.


The “desired result” is the result a designer would expect, while the actual result is technically correct.

This had the effect of making the hand of my newly minted bread cursor (with the most edges) look “washed out” because the two lighter inner layers were covering the outline.


The solution for this problem is to ‘supersample’ the cursors in our build scripts. Supersampling is when you render the image at a much higher resolution, and scale it down to the desired resolution. Instead of going directly from Inkscape to a final image, we first export each cursor to a temporary file which is 4x standard resolution and 2x double resolution. We then scale down and copy that image to the final resolutions.

The end result is going to be the option for us to more easily use sub-pixel detailing in cursors without worrying about losing smoothness; any extra detail may not be noticeable on a day-to-day level – but it’s the polish Plasma users are beginning to expect. Additionally, high-resolution cursors will also benefit because the half-pixel details will become full pixel details, and on a high-quality screens you’ll have ultra-sharp graphics.

breadAnd that’s how bread is helping make Breeze cursors pixel perfect!

Now, super-pixel-perfection isn’t that noticeable so there’s not going to be a rush to update existing cursors; but if one day you quietly notice your cursor is a little bit sharper than it used to be – you can thank bread.

Download The Cursors:
(extract “compiled” cursors to your icons folder to install, or download the source to edit or remix them. Golgari is a green/black theme)

Bread Source
Bread Compiled
Breeze Golgari Source
Breeze Golgari Compiled

Plasma 5.2 – The Quintessential Breakdown


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.

KDE Frameworks 5.3 & Plasma 5.1 – First Impressions

Today I took the plunge into the next-generation KDE desktop, performing a dirty upgrade from Kubuntu 14.04 to 14.10 before installing the plasma-5-desktop package; and this is my first impression of KF5.x and Plasma 5. This is also a bit of a primer, because when Plasma 5.2 enters the stage I’m interested to see the comparison and do a second write-up, using my experience in both 5.1 and 4.x as points-of-reference.


The Old & New

Many KDE applications are in a transitional state and not migrated to KF5, so summarising the applications’ of KF5 as “uneventful” is apt because there are literally no events. I don’t know how a great deal of this is being handled, and it could just be from my method of installation, but aside from the system settings panel almost all the core applications are still running KDE Frameworks 4. Uneventful can be good, and I’d rather apps take their time porting to KDE 5 than sloppily rushing their ports. So, upgrading to the next-generation won’t gut your applications, and that’s a good thing to know an upgraded desktop won’t be paired with potentially unstable apps.

This makes me note how differently this iteration of the frameworks has been handled in contrast to Frameworks 4; there’s no mad science going on here folks – this major transition is being handled with caution and care.

Widget Shuffle

When it comes to the desktop itself, the reserved nature of the application updates speaks nothing of what you’ll get with the desktop widgets; a complete replacement of everything you’ve got. This sounds obvious, but at first blush while KDE looks similar to its forbearer with the white panel at the bottom, sporting the same widget selection and placement as its predecessor – that’s where the desktop similarities end, and it’s probably easier to name what’s stayed the same than everything that’s changed. This all makes sense, because swaths of the desktop *had* to be re-written, and the authors didn’t want a rocky transition this major release.The changes I did encounter aren’t flow-breaking and you won’t feel like a drunkard stumbling around unfamiliar territory, it’s still got KDE DNA and while you will have several “oh that’s different” moments: I’m glad to say they’re mostly good.The bad news first though; at least in Plasma 5.1 many of the widgets you may have used simply don’t exist yet. New and returning widgets are in the pipes, and with time they will surely return with the same level of polish found in the current crop of widgets, but with such a dramatic re-write it will take a few releases for all the widgets to catch up.

The good news is that the Plasma goodies which do make an appearance are universally improved. KDE has fully committed to QML as the language used for programming desktop components, and this decision has yielded a much more consistent desktop. It’s one of those things which is difficult to put your finger on, but it’s all just a little more cohesive.


There are a few notable new widgets and behaviours I’d like to specifically mention. The new search widget is shockingly fast, organised, and a hidden treasure. The notifications tray has been reworked; it’s easier, simple, consistent, and often integrates controls more smartly than before. The applications menu launcher, despite having no outright usability differences, also “feels” better.

Stability & Bugs

I’ll say this outright; KF5 and Plasma 5 are not nearly as mature as yesteryears KF4-based desktop. After installing the update and doing a complete reboot I’ve suffered several crashes, and Plasma had at one point managed to forget my colour and wallpaper settings. A second restart seems to have shored it up, and the desktop now seems to be stable; perhaps it had to overcome stage-fright? I’ve had several issues with the Plasma desktop, ranging from the desktop placing the ‘add widgets’ tray into the middle of the screen (seemingly “docked” onto a window), and the system settings application behaving like a petulant child.

With all that aside, for en early revision of a recently overhauled desktop environment, (after it calmed down) it’s become more stable, and it’s been running a full day without issue. With that being said, I’ll be looking at 5.2 before I take a more firm stance on stability and making recommendations based on that factor.

Performance & Animation

I have one of those huge Aluminium Mac Pros which I’ve upgraded it significantly during its’ lifetime, yet despite my heavyweight computing power and KDE never feeling ‘slow’, I must admit often times it didn’t necessarily feel ‘fast’ or ‘smooth’. With KF5 and Plasma 5 the desktop for the first time feels *smooth*, please understand I’m saying it feels buttery, slick, and silky in all the right ways.

This can be attributed to Qt 5, which has moved to a hardware-accelerated graphics-stack, and while KDE has taken advantage of hardware acceleration since KF4, it was not nearly as pervasive throughout the entire toolkit as it is in this most modern environment.

There also seems to be fewer visual glitches associated with the desktop; KF4 had some minor issues where it might blur a background or draw a shadow before whatever content was to be placed on the screen. KF5 and Plasma 5 have reduced these issues, but odd moments of ‘hiccups’ which reminded me of KDE 4 can be rung from the system if you launch an unloaded plasmoid from the panel. These visual hiccups are incredibly minor, but do detract from the incredible mirror-shine polish that I feel will become expected of the modern Plasma desktop.

This can be seen a split-second before the content catches up and fills in the popup.

This can be seen a split-second before the content catches up and fills in the popup.

Animations throughout the Plasma desktop are both more pervasive, consistent, and smooth. Everything feels animated, and it makes the desktop feel more alive. The animations and movements within widgets themselves look consistent, and are overall much more tied together. It feels less like desperate parts bolted onto a desktop, and more like a single whole dancing to the same tune.

Look ‘n’ Feel

Once again, a disclaimer; I’m a member of the group managing this aspect of KDE.

Out of the gate, Plasma 5 is both more and less visually polished than the Plasma 1 experience, it’s give-and-take. Generally, the “new look” (named “Breeze”) for KDE aims to be simpler, less cluttered, and more ‘designed’. The layout of just about everything has improved dramatically; this is in blatant disregard to your selected theme, being a core improvment on an applications’ and widgets’ level. Things don’t feel so tightly packed together, and it allows your eyes to rest more easily.

(as a side note, in my screenshots I’m using Oxygen again)

The new applications’ theme (as it stands in 5.1) can feel Spartan, with reduced chrome in the windows, more focus on spacing, and whiter default pallet. These are still clearly the early days for Breeze, and quite simply it hasn’t had the 6 years Oxygen has had to fine-tune its design and mature. That being said, it’s a very different style in it’s most core concept: Oxygen had head-first jumped into an extremely heavy and visually intense theme which gradually lightened itself up, while Breeze has started with an extremely minimal design.

The majority of toolbar icons no longer have colour, instead using a monochrome design, and it can sometimes take an extra few moments of searching to locate icons you’re looking for on the toolbar. This is offset by vivid content icons which readily call to your eyes, sporting near-pastel colours and thoughtfully laid out structures. Overall, the icons shift focus away from the UI and towards content, and you really don’t feel like the chrome of the windows is there.

The end result of all these changes is a much lighter feeling KDE. The UI gets out of your way more, and instead of attempting to woo you with distractions it’s clear the next generation desktop will have a reserved respectability in terms of costly design choices that will create a more elegant environment.

Settings & Configuration

Plasma 5.1 is configured to feel a great deal like the traditional KDE desktop, with the standard panel, mouse actions, and shortcuts, but things diverge a great deal in the system settings application which has been completely rearranged. Previously the grouping of the settings menus felt random as they were built on the leylines of technical details over user-oriented goals, while in Plasma 5.2 they are more sane to users, being grouped more by goal than underlying mechanics.

Desktop configuration (specifically managing widgets) has been incremented upon, with some changes feeling slightly arbitrary. The “add widgets” panel now slides in from the left and adding widgets now presents a “drop indicator” which illustrates where on an underlying grid your widget will be placed to help avid widget-users keep everything aligned. Widgets still have the slide-out drawer, which can often seem strange in how you interact with it – but it’s unchanged.

Several widgets on KDE which beg for configuration options open up bare settings dialogues, such as the search widget. While this is a minor nit-pick, it’s the type of issue where you know the first step is still going to be building the selection of widgets available, and you’ll need to wait to play under the hood of the high-quality widgets bundled with KDE.

Final Notes

KDE Frameworks 5 and Plasma 5.1 create a fine environment, but one that is still visibly in it’s early days – you could almost say it suffers from many small papercuts, avoiding the haemorrhaging issues that soured the initial KDE Frameworks 4 release. With a completely re-based desktop I don’t feel these little cracks will remain for long, as it seems the developers have a firm grasp of what needs to be done and exactly what they want to do. For a major point-release, there’s a real feeling that this software will reach rock-solid stability very quickly given the state of it as it stands.

Now, do I recommend Plasma 5.1 for general use? Compared to the current 4.x Plasma release?

If you were installing fresh I’d say go for Plasma 5, but if you were just considering an upgrade, I’d wait. Plasma 5.2 is coming in hot, and I believe it will be the beginning of this next-generation desktops’ serious push to bring people to this fine new desktop. Even if it doesn’t reach feature-parity with the previous desktop, I imagine 5.2 will be the ice-breaker for the interested public with 5.3 will more/less beginning the larger migration to the 5 series desktop.

Curses! … I mean, Cursors!


In the upcoming release of Plasma we’ve done some work on the humble cursor; we’ve added a few missing states, and there will also be a brand new “snow” version, along with minor tweaks to the existing Breeze cursors. But me being lazy and the merge window having closed, there are a great many more cursors which haven’t made it into this release, so I’m putting them here for everyone to use and redistribute.

All of the cursors I’m posting will have 2 versions; the source and the compiled versions. Download the source if you’d like to edit, remaster, or improve the icons – build instructions are included, and our build script has been significantly improved and should be pretty easy. If you just want to use the cursors download the compiled version and simply extract them right into your icons folder (usually found in /usr/share/icons/) and enable them in your control panel.


Not much has changed, but if slightly softened shadows and diagonal cell-sizing cursors are important (or you just don’t have the default cursors) then here they are;

Breeze (Source)
Breeze (Compiled)

Contrast Cursors:

Probably the most important cursor set I regret not getting into this merge quickly enough is a new contrast style; so if you or someone you know is a visually impaired user, I’d like to offer this new cursor set. I can’t claim to be visually impaired myself, so if there is a user who is visually impaired I would like feedback on this particular cursor set and its usability. It also comes with an extra-large size as well.

Breeze Contrast (Source)
Breeze Contrast (Compiled)


Hax0r3d! Some people love it, other people hate it; here’s a colour-matched cursor to accompany the “Ghost” “hacker” style.

Breeze Hacked (Source)
Breeze Hacked (Compiled)


Is the dark default cursor not dark enough?

Breeze Obsidian (Source)
Breeze Obsidian (Compiled)


This was a widely requested style; white Breeze cursors! These cursors will be in the upcoming plasma release, so if you’re upgrading, you can skip installing them.

Breeze Snow (Source)
Breeze Snow (Compiled)

Other Colours

Amber, purple, blue, and red… ‘Nuff said.

Breeze Amber (Source)
Breeze Amber (Compiled)

Breeze Purple (Source)
Breeze Purple (Compiled)

Breeze Blue (Source)
Breeze Blue (Compiled)

Breeze Red (Source)
Breeze Red (Compiled)

Glad I Took the Time

Hello Planet; This post isn’t about KDE specifically, but about taking time off to avoid burnout, and the importance of understanding when work has gone too far. If you’re a developer, please remember that rest is important, it’s an important part of developing great stuff. If you’re a user… You might get something out of this if you’re a workaholic.

In about an hour a few short minutes, I’ll be stepping out into the ice-covered Canadian landscape to once again wander towards the off-blue cubicle I call home for 8 hours a day. It’s a bit different than usual, because it’s the first day back from the first real vacation I’ve had in a number of years.

I’m a workaholic, and slowly I’ve also been burning out. I work when I’m in the office, I’ll work when I’m on break, I’ll work at home – and thanks to the all-glorious superphone – I’ve even found ways to work on the bus. May the dark lord Satan help me the day I get a tablet, because I know that too will let me do even more work. I’ve caught myself several times doing work at the office – and then waking up when I reach into the IT closet to be pulled in by wires vibrating “YOOOUUUU HAVENNNNT ZIP-TIEEED USSSS, THAT LIGHT ISN’T BLINKING HOW IT SHOULD, GRRAAAAHHH” – waking up to know I’ve been working in my dreams again. About the only times I’m not working in some way are during the odd card nights, and even those make me apprehensive. So, in the days leading up to my vacation, of course, I had planned some “light work”, “relaxing work”. I’d make one website, do a bunch of art, and get a jump-start on my January workload, among other things… Nothing major I told myself.

Then something weird happened. I had always planned to take the first day of my time off, off. I was sick, sick to my stomach that day because I wasn’t working – I had so much to do and I had promised myself not to do it for one of my sixteen days. The next day, all the work was still there – waiting – and while doing other things it dawned on me that I was actually a little burnt out, the smoke coming from my ears was pervasive enough to cloud my apartment and smog out the glowing silicon device waiting in the corner. I hadn’t realised just how mentally drained I was becoming – like an undead walking from keyboard to keyboard – typing arcane commands with so little passion.

A trend began and soon I realised I had taken some full days off, and family visits claimed even more. On the first Saturday of my vacation I once again opened Kate and started punching in lines of code. That day I had been something I hadn’t been in a very long time: rested. It dawned on me while writing code that maybe this vacation time was not the time for clocking-in, but for checking out. I fought my brain, I fought every impulse firing through my neurons, and I pushed my keyboard away from me. I was never so turned on by being shut down. I felt irresponsible sleeping fully, dastardly for sitting on messages calling on me to my computer, and vile for letting all that work fester and rot. My dreams involved endless pits of encroaching cords and demonic follies of co-workers demanding I resume my pursuits.

But the world still turned. Even without me dragging myself to the helm navigating choppy seas in the dark, everything kept spinning. I’m not a big “personal revelation” guy, but I had forgotten the importance of time off, that burnout is a grindstone which churns away at you, and one that’s easily preventable. All the work I had to do is still there – and some of it I did – but almost all of it waited without too much disturbance. There’s no need to damage oneself over a deadline, or a merge window, or a last-minute request. Sure, once in a blue moon it’s good to let stress focus you – but it’s not a state you should constantly keep yourself in.

I was irresponsible in how I left my work. I went fairly dark, and left no explanation to those who have been waiting patiently. This I could have handled better. But the more important fiddlybit I’d like to express from this post is one thing; Most of the people likely to read this are as – or far more – passionate about technology than I am, and today we almost all have technology at the holster allowing us to constantly be on. A single ‘ding’ in our pockets can call for hours of our time any time; it can hurt, it can be painful, it will make you sick… But take a few moments and really think about the last day you were really truly off, and if you can’t recall it, remember you have all week to examine your weekend – and really, really ask yourself if turning off your phone and shutting your workstation will really result in catastrophe. Will missing a merge window end the world?

So, tl;dr:

Burnout is a slow grind dulling the knife; allot yourself some real time off. After two weeks I already feel refreshed from years of constant stress and work. One day every weekend to yourself won’t kill your projects and undertakings, and you’ll be all the sharper for it.

I would also like to point out; the KDE VDG is awesome. I essentially disappeared for two weeks (in a very irresponsible way), but when things had to be done they got done. I wasn’t elegant in how I dropped the ball, and I should have said ahead of time when I decided to rest – but they handled it (Kudos, Uri!); trust your peers to handle things if you need to take some time for yourself.