It’s that time of the release cycle! Plasma 5.9 is getting a new wallpaper, “Canopee”, French for canopy. Like the last wallpaper, Bismuth, we are again shipping with a 4K version.

(Download)

This wallpaper is aiming for the same effect as Bismuth from Plasma 5.8, but the colours have been turned down from “11”.

The development of this wallpaper was a little bit harrowing; I had several designs which were started and scrapped in rapid succession. It’s easy to imagine a few lines in pencil as looking good, but in reality only the initial vector work will tell you if it’ll work. Inkscape for some reason also evolved a rather massive memory leak, swelling to 5+ GB of RAM usage after only a few dozen gradient adjustments, sending my machine grinding to swap.

As I worked I kept snapshots of various steps, so I’ll cover how this wallpaper was put together:

The first part of the making Canopee involves using Envelope or Perspective in Inkscape to set up the initial grid of ‘polygons’, trimming excess, then punching out the unique layers. Unlike Bismuth which had one layer of polygons at varied heights, Canopee had several complete layers of overlapping polygons.

The next step is adding gradients and closing the seams. I need to add the gradient first otherwise I can’t see what I’m doing when I close the seams. If I don’t close the seams you get those white lines you may have seen in the early 5.2/5.3 wallpapers. Below is after I added the first set of gradients, and the first few rows of “closed seams”. Seams are closed by making every triangle overlap slightly, so I start from the back and manually adjust nodes for every ‘polygon’ in the wallpaper.

(Yes, manual. If you’ve been paying attention, each successive wallpaper has more polygons. I am, in fact, being slowly driven insane by this)

After getting the water and track done, the next step is the island. You can see that welding the seams makes things more solid. I’ve also made the yellow layers semitransparent, later they’ll glow with a soft light which is accomplished by adding a blurry solid underneath the layers.

The “grass” will use vertical jittering to add texture and visual interest. This is actually one of the more time-consuming tasks as it requires huge amounts of manual correction and visual fixes. ‘Polygons’ are more often than not above and below each other when they shouldn’t be, and I have to manually add walls to make them look like columns. This is also the most error-prone part of the process, and some mistakes were caught as late as after adding post-processing in GIMP, meaning several fixes often have to be ‘backported’ to the master vector file. It was also at this point that I decided to dump purple and use exclusively ‘natural’ colours.

Finally, I add various fine touches, including reflections, more refined shadows, large glows, particles, etc. At this point everything is set in stone, so I create 3 more layers which will serve as masks in GIMP when I do post-processing. Each mask covers one area which I’ll want to apply a specific effect to; I try to use slur, pick, and thread filters on “liquids”, and noise filters with varying adjustments on other materials.

Finally I composite it all in GIMP at a 5120×3200 resolution. This wallpaper had a huge number of corrections in post, including one missed glow, a small run of polygons which were ‘flat’, and several mistakes in the jittered layer. After those corrections the final result is at the top of this post. This wallpaper will be available for Plasma 5.9 at 4K resolutions, but if you can’t wait to get it the top image links to the 2560×1600 version.

I’m very excited to let everyone know that as of tomorrow I’ll officially be joining Blue Systems, working full time on KDE and related projects! The chance to really immerse oneself completely into something you love and also work alongside people you absolutely respect is mind-blowing.

I would like to deeply thank Blue Systems for this opportunity, I hope my contributions will match the awesome generosity that everyone in the community has given allowing me do this. Thank you!

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.

Here’s the 5.7 wallpaper, “Skylight”;

(Download 2560×1600)

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;

1. Where would you want all the wallpapers stored? A ‘legacy wallpapers’ package, the current additional wallpapers package, OpenDesktop?
2. 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!

During the Sprint at CERN everyone got to take a tour of the Large Hadron Collider, it was a fantastic time and a proud moment for members of the KDE community to see the massive and incredible machines which happened to have KDE software running at the controls.

There were many different systems on display, not just KDE!

We had a rare opportunity to actually go 100 meters underground and look at the scope of it – grand and atomic – and look at one of the greatest achievements of society with our own eyes.

There were many different systems on display, not just KDE!

Once we got our eyes on the massive structure a couple of the guys pulled out a bag and said “Hey, want to see something cool?”

Of course.

There were many different systems on display, not just KDE!

Over at the injector (where they feed matter into the LHC) some of the other VDG members had snuck in a bag of paintballs. It was ON. Much like a pneumatic tubes of the late 1800s, the LHC consumed the ammo with gusto. I was sure our giggling would give us away, but we made sure people crowded around the controls before anyone knew what we were doing.

There were many different systems on display, not just KDE!

The way the LHC was laid out, there was various catwalks surrounding where the beam passes through. We found a pair of convenient walkways ripe for us to jump across which would let us get hit – we didn’t need to worry much about timing, after all, the gauges already indicated the first paintball was going 92.3% the speed of light.

The first hit! Left a small mark!

It was a good time. We had some bruises, other peoples heads and arms simply vanished at near relativistic speeds. We lost 3 members of the VDG, 5 WikiToLearn editors, and Sebas was the only Plasma developer to go, though watching him get sucked into a black hole made by a near-light-speed paintball was really, really cool.

As an aside, since he’s beyond the event horizon, I’ve taken over his blog. Any amazing accomplishments he makes from now on were actually all me, and I should get the credit.

And that was our tour of the LHC. We’re confident in our productivity to take over for the now deceased community members, and we firmly believe the sacrifice was totally worth it. After the tour we got into our cars to drive back to the sprint proper – albeit with some more shoulder room in the vehicles – and we got back to work after turning the LHC into the worlds largest paintball cannon.

After a seeming eternity the unthinkable has finally happened; DWD has been discussed formally on an implementation level and it’s exciting to say that some parts are now under development. Thanks to the CERN Sprint we’ve had Martin Gräßlin, Sebastian Kügler, a couple others, and myself in one room able to make final decisions on how it will all come together.

Dare I say DWD is officially real, entering development, and coming? Yes!

Previously I’ve made two posts about DWD concepts, this post will summarize the basics of DWD as it has been finalized. Some parts of both designs previously posted have been used and I’ll make another post later including mockups with more detailed information, but for new here’s an overview of DWD basics;

Low-Level IPC

DWD will use D-Bus as its IPC, being implemented via the KWin Window Metadata Tier 1 Framework. This is for Qt/KDE driven implementations, but anyone can implement DWD via D-Bus.

Core Structure

At its core DWD will work with ‘Semantic Objects’ and ‘Priority Groups’. Semantic objects refer to things like ‘media player controls’, ‘navigation’, and ‘actions’. Applications bundle Semantic Objects into Priority Groups, then push those groups to the window manager.

The window manager will tell the app whether a group was accepted or rejected; a group is rejected if any single semantic object in that group is denied for any reason. Higher priority groups get first swing at embedding their controls, and it may affect widget placement in certain situations, such as phone controls.

From there applications just hide their own elements in response to what groups were accepted. There will be some events and flags as well, but we won’t get into that yet.

Customisation

One aspect to note is that DWD will offer no customisation on the client-side. I had gone down that rabbit-hole in an early draft and we all deemed it overcomplicated. Ultimately what applications need to know is that the controls are being served – not how or where they’ve been served.

One thing we did was look at is Gnome CSDs which offered all the craziness applications could possibly want, and we noticed they weren’t actually being all that crazy with it. Generally the same controls made repeat appearances and when it really comes down to it in practice there’s not much of a value in extreme customisation. As we said previously if you need extreme customisation and weirdness this may not be the method for you – which is fine. At the same time we would recommend application authors examine why they would need exotic controls, and why they specifically need them in the windeco.

Stewarding the Protocol

One thing that was discussed was who and how to steward the protocol. When I first posted about DWD there was backlash about KDE being a ‘protocol gatekeeper’. Afterwards I proposed an extension-based design which also had backlash because it could make the protocol technologically ‘complex and messy’.

Ultimately we decided to steward the protocol and simply work with anyone who wants to be included in the design process directly. We will accept input into where the protocol will go and provide any resources we can.

One thing that was made clear was that some groups are uninterested in considering the DWD approach after being asked. We all agreed it’s not worth making a convoluted extension system just to cater to groups which probably won’t participate, instead focusing on making the best protocol we can for those who want DWD. For those environments that will not support DWD I’m glad to say that it’s still 100% compatible and applications using it will continue to work as normal, they just won’t have content in the decoration. We will not be breaking other environments.

Again, we’ll be open and welcoming to anyone who wants to join us in working on and implementing DWD.

The Implementation Plan

Right now early work is being done on our existing frameworks to move them into position to implement DWDs. Once that is done we’ll implement the protocol with a minimal number of Semantic Objects, and using the low-level API port a small number of simple applications as a beta. Applications being considered for initial DWD tests include Konsole, Kate, KCalc, and similarly small apps with basic requirements.

After the API has proven itself on smaller-scale applications we would move up to heavier applications. KDevelop was mentioned specifically as a candidate as its relatively heavy UI could benefit from space-saving DWDs while developers could very quickly give us high-quality feedback. This may be where we move to higher-level classes which will hide away the group/object system as well.

Designs & Reference Material Incoming

I’ll be making another post later with designs which should be mostly accurate to what the final protocol will produce; accurate enough to place in the Wiki as design references for how applications should look when using the final DWDs.

While Martin will continue focusing down Wayland and making excellent progress, he also had a rough timeline for when we can expect basic DWDs make an appearance. I won’t quote him as it was an off-the-cuff estimate, but it’s exciting to know there’s light at the end of the tunnel, and that we’re out of the conceptual phase.

On a complete aside it was a complete pleasure meeting everyone. Great to see some of the friends I met last year again, fantastic to make many more new ones, and I wanted to thank everyone in the Sprint as well as those who supported it for making such a great event happen.

Special thanks to CERN for hosting this Sprint! Be awesome and support future Sprints by clicking the links below;
Via Paypal for one-time donations
Become an ongoing contributor and official supporting member

The Sprint in Geneva has been a bustling experience, there’s huge amounts of throughput from every participant, and seeing the progress is exciting. There will be a great many blog posts from many people with thrilling progress. I can’t spoil everyone’s work, but I can share at least a few things.

The first is weather! It was previously announced that Plasma 5.6 will be seeing the return of the weather widget. Lots of design work and planning has been done for it and while not everything we discussed will make it in for this release I do happily get to show off our new Breeze weather icons;

There’s more which will be added, but this is the base set which reaches parity with the Oxygen weather icons. Things like high wind, smog, and sandstorms are all in the works.

I’m very excited to announce an updated colour palette. The palette that we’ve been was the formal ‘core’ Breeze colours with an few extended colours I threw in for icons. While it got the job done, we’ve very obviously been using colours not in the official palette for icons using pastels and off-white tints on several occasions. The extended colours were also a bit ad-hoc, with some cases where gaps in hues and luminosity would limit what we could do if we rigorously adhered to the scheme – one thing I did in the wallpapers . Here’s the third iteration of our palette;

It’s not yet in the wiki, but we do have it in GPL format for use in Inkscape, Krita, and GIMP (special thanks to the colour dropper widget which greatly speeded up the process). It’s not completely 1:1 with our existing colours, but it’s close enough and we’ve played loosely enough that it’s not obvious which upcoming icons use the new palette and which use the old. Eventually we may look at more formally updating existing icons, but it’s a low priority. I’m very excited for what this palette will let me do with wallpapers, as I can now make brighter wallpapers without them being over-saturated.

There’s so much more happening, but it’s impossible to write about every detail.

Support the great work of passionate Contributors via the links below!
Via Paypal for one-time donations
Become an ongoing supporter and official supporting member

Yesterday I landed in Geneva, ready to participate in the 2016 multipurpose Sprint at CERN.

After a successful touchdown, I somehow dragged myself onto the CERN campus after over 20 hours of riding trains, flying, waiting, and running. Half dead and ready to drop I got my bearings around the campus while keeping an eye out for other Sprint Participants, and I have to say my first impressions of the facility were shock and awe; more amazing than I could have anticipated.

Of course I was too tired to appreciate it, and I kept pestering the hotel staff to see if a crashpad was ready.

All at once everything seemed to come together and I ran into Alex, Riccardo, Kai, Martin G, and Sebas in short order. Today was just my arrival day, so I wasn’t breaking out the laptop and starting intense development or planning sessions with anyone, but even in our casual conversations we all excitedly at one point or another started planning to plan exciting things.

Right now? I’m waking up, looking at the view (pictures later, probably will update this post) and ready to get started.

Support planning to plan and donate to the KDE e.V.!
Via Paypal for one-time donations
Become an ongoing supporter and official supporting member

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.

You can read it here:
KDE Plasma 5.5: The Quintessential 2016 Review

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!

Since Martin posted his Wayland progress I’ve noticed an uptick in questions about CSD, so I figure now is a good time to upload this post I’ve had sitting around, as for the past month I’ve been closely examining the concept of “Dynamic Window Decorations”, or “DWDs” and how to better implement them.

When Last We Saw Our Heroes

For those who need a primer or reminder, DWD is the sister of “Client Side Decorations”, or “CSD”s. Both CSD and DWD are methods for placing widgets in the frame area of windows to save vertical space, look cleaner, and either make applications feel unique or more integrated.

Indeed, DWDs would be themeable like traditional decorations, fully supporting transparency effects.

CSD charges the application with drawing the whole window including the frame, instructing the window manager to discard the provided frame. This is the method used on Windows, OSX, and GTK. DWD is aiming for the opposite approach; the window manager continues to draw the window frame, but the application can request certain widgets to replace the window title. Martin Gräßlin plans to keep as much as possible on the server-side as there are many important advantages including customisation, stability, trust, and integration.

DWD “1.0” Was Getting Complicated

One thing CSD will always have over DWD is customisation; when an application has free reign over the whole window it can literally do anything; it can make windows round if it wants to, it can invent crazy widgets and put em’ in the title area, and more. DWD isn’t suited to this, and while designing the first iteration of the protocol I tried to bang a square peg into the round hole by providing those many possibilities.

In my infinite wisdom I re-invented X, with a sprawling protocol that covered dozens of edge-cases which would likely never be used. Even with that, people still complained about the fact that many customisations would still impossible. People also didn’t like the KDE crew being the stewards of this protocol, as different environments want to do different things.

DWD, as originally envisioned, had to change – it was just too complicated and inflexible. Listening to the feedback it was clear the protocol had to be simple, flexible, and tractable. A large requirement was also making it able to grow outside of KDE with or without our ‘approval’.

DWDs New Approach

DWD, as I have drafted it, has been boiled down to a discovery service whose sole purpose is getting apps and window managers to figure out compatible protocols, and specify some standard UI controls which will use those protocols.

Here’s the quick overview on the current core “DWD Protocol”, again, as of my current draft (which could totally be rejected):

• DWD will be organised into “extensions”. Extensions are just blueprints listing required D-Bus specifications, widgets/controls, and options.
• Applications and the Window Manager handshake for compatible extensions.
• Applications tell the Window Manager what controls from those extensions it should display, and how it wants them laid out.
• Applications hide their native controls.
• DWD is done and gets out of the way at this point. Control is handed to specifications like MPRIS2, and Window Managers (or Plasma) control the app through those protocols using the requested controls.

That’s it, DWD “2.0” in a nutshell.

KDE will need to create some reference extensions (plus some D-Bus specs) and hopefully everyone will be happy enough to standardise on the basics. From there any environment can create specialised extensions for DWD, we can work with extensions we like, and maybe standardise on the really useful ones (much like libinput has been folded into many environments). If someone makes an awesome extension that handles admin access requests, we could use it. If we make an extension that handles progress charts, someone else could adopt it. I’d like us to develop two reference extensions: a basic toolbar extension, and an MPRIS2 extension.

Advantages over “1.0”

Security is the biggest upside to offloading work on other protocols. DWD doesn’t care how the standards are implemented, so they can be as secure (or insecure) as they choose to be. Security issues or weaknesses in the protocol itself will be mitigated, as the protocol is much smaller. Patches for applications or changes to functional protocols can be made without breaking DWD.

Integration is also another bonus. Parts of the desktop can integrate the protocols extensions use, without DWD needing to explicitly support it. The best example is MPRIS2, which already exists and has amazing support everywhere. The idea behind DWD is that we create more MPRIS-type extensions as we need them.

Finally, core DWD is out of the hotpath for data passing. Window Managers don’t need to be “like X” and conform to complex drawing and customisation tasks. Hopefully as a de-stresser to Martin, this method of offering DWD will be much more easily implemented in a plugin architecture which can be gradually expanded upon. We won’t need to have the full protocol out-of gate, and environments can start with the bare basics and evolve as useful extensions are finalised. I don’t know how he might want to do it, but DWD extension plugins could be potentially be maintained entirely outside of Kwin (or other Window managers) if we play our cards right.

The Downsides

Nothing is perfect, so of course there are downsides;

Customisation.

The big elephant in the room. Going over more standard protocols (and not bloating the new specification) means applications will have no say over how content is styled in the window. I considered this for a while and ultimately decided that it’s O.K.

We could still offer a few more standardised ways of doing common things we do today, such as passing a colour palette to sync with the window, but outside of the handshake I’ll push for an extension-over-integration policy.

The application doesn’t need to know how things are done, only that they’re getting done. The WM knows more about the environment it’s in than the application; functionality is what matters. The volume button on a computer might be shown as a slider, but on a touch-device it may be a larger button with a popout slider. Maybe a phone will simply use the hardware controls. It’s up to whatever is managing the control.

For people already seething with rage ready to point at me and say “Linux is about choice! Applications should choose what their UIs look like!” I will point out; applications can chose not to use DWD. They can choose to implement a CSD-based application. But lets be real here: when we find a need for speciality widgets, if they are really something useful, their host toolkits/environments can always add the extension.

Generally though, if an application is doing something really unique it’s probably doing it’s own thing anyway – like Chrome/Chromium – or breaking the local HIGs. If you absolutely need to save that 18px while also showing a one-of-a-kind rainbow-powered rocket-widget which must be in the frame… CSD is the price of needing to be that special.

Fragmentation.

With anyone able to create extensions, there’s a change we might have a situation where two environments create two similar offerings. For this, I believe it’s a chance for everyone to experiment, and then work together to standardise. The one thing this means is that applications created for another environment might take longer to get CSD-like functionality, though they should present their interfaces in their traditional application UI.

I think this is still better than CSD, as often a broken CSD is unusable vs a DWD which will simply not conserve space.

DWD

So, in the end, this is the direction DWD has gone. Keep it simple, let anyone decide how it should be used, and piggyback off of proven protocols.

MPRIS2 shows what a purpose-driven protocol can do, and already has lots of examples of “remote control” interfaces. Outside of MPRIS2 we would create missing D-Bus specifications which would hopefully make the wider applications library accessible in a similar manner. Specifications for things like progress management, search, sharing, and many others could be created which will benefit applications, and allow deeper desktop integration for everybody.

For those who saw the previous designs in my original DWD blog post, not much has actually changed visually. Everything I posted is still possible, but now we have a much more practical way to do it which I am much more confident we could reliably implement and share.