Aether Icon Theme

What does everyones second-favourite Canadian developer do when he wakes up in the morning? First he makes coffee, usually by pouring coffee grounds and hot water directly into the sugar jar then drinking the resulting syrup. After that while he waits for the resulting diabetes and caffeine to kick in, he usually warms up for work by drawing a few icons to get into the productive mindset… This has been going on for a while.

So I’m pleased that this non-project has become complete enough that I believe I can share it around with the world a bit. Before I go on, I would like to express that this set is not an official project at this time. It may also randomly go totally unmaintained at any moment if the right people decide to strangle me.

Because I’ve been naming everything I get my hands on “Aether”, without further adieu I’m excited to present the Aether Icon Set;


Everything needs a logo.


The Aether icon set takes cues from several existing icon specifications, along with heavy influence from Material icons. My hope is that icons from this set could present on Android and other platforms without seeming too out of place. As KDE applications make use of our mobile and convergent frameworks, it will in time become just as important for our artwork to be as portable as our applications.

The general design of the icons includes the use of folds, scores, and simple linear gradients inspired in equal parts by the concept of Kirigami and Material. Folds which visibly protrude from the icon may cast simple shadows. Icons generally aim for a middle-level of detail seeking clean and bold designs, and while there are keyline shapes it is encouraged to break from them for more dynamic silhouettes.


System settings and devices. Still a long way to go in this department.

The icons set is based on the ever steadfast Breeze icon set, and the intention is to retain the monochrome icons from Breeze while injecting a new set of full-colour icons to compliment them. Currently Aether requires breeze be installed on the system, as it will request Breeze icons in the manifest. It also lacks the coverage we enjoy in Breeze, so it’s also good to have it filling the gaps in Aether. While I do intend to use the Breeze monochrome icons, in some instances monochrome will eventually be overridden with colour icons for things like places and mimetypes for consistency purposes.


Folders in a variety of colours.

The Aether icon set currently contains over 150 new colour icons at 64px in scalable vector format. Of these, the vast majority use entirely original art, with a handful taking matching assets from Breeze and undergoing modification to fit the Aether aesthetic. The icons are designed so they can render quickly on the web with no loss in quality, as the modern web demands high-quality low-impact imagery in extreme DPI situations. I believe this is the most important aspect of design pulled from Breeze.


Applications, including Libreoffice and Qt development suites.

The Aether icon has a strict set of guidelines, along with a keyline template and an entirely new colour palette. The specification of the icon set allows the 64px icons to scale to 32px and remain pixel-perfect, with some icons scaling down to as low as 16px remaining completely readable.  This is not the long-term plan, and smaller sizes are already receiving partial coverage.


Folders are the most complete icons in Aether, with 16, 22, 32, and 64+ size icons available.

You can get the aether icon set via a scratch repository here:

Even though I haven’t added the license to the repository yet, these are being placed under the Creative Commons Attribution-Share Alike 3.0 Unported license at

The scratch repo contains some working files and resources for those interested in contributing, but currently I have not written down the specifications. By reading the Google Material icon guidelines you will be roughly halfway there, but there are enough subtle differences to trip anyone up. In the scratch repo there is also a set of resource files with working master files, inkscape palettes, and extras.

If there is contributor interest let me know and I will write down the guidelines along with examples. Until then, I’ll accept contributions directly and simply adjust them as necessary if I’m able to fit them into Aether; this is still a very informal side project.


Does look funny to you?

Our stalwart KDE homepage, which has been with us for several years, has, after serving us well, finally been retired.

The new homepage, using the new theme “Aether”, is only the first step of a much longer journey to unify the disparate KDE websites. and its surrounding network is made of many parts: forums, wikis, feed aggregates, custom solutions, etc; beyond the homepage each of these will need to be updated. It will be a long road, but the modernization is due.

This new design is still using direct and simple PHP, but the redesign effort will see us land this into a Drupal theme which will eventually be deployed for the wider pages. We will still be using the other systems for our other non-static content, but Drupal will be used to replace any page using our current template engine “Capacity”.

I’d also like to give a special thanks to Harald Sitter for making this very quick and smooth transition possible.

If you spot any issues with the website, please report bugs to, and I’ll watch the mailing list as well.

Wallpaper, Wallpapers, Website!

Starting off the Plasma Sprint today has been a good start with a little bit of real-world trolling, some quick sight-seeing, and of course, starting to get todos scratched off the list.


Nobody noticed when this was stuck outside the window, and we are happy to report there’s a vast array of KDE software available for Windows. 😉

I’m excited to say it’s that time of the release cycle, meaning we show off a new wallpaper coming to Plasma 5.10!


The new wallpaper is named “Cascade”, English for many interesting things in technology, and French for Waterfall, or many waterfalls. Interestingly, this wallpaper has more layers than the 5.02 wallpaper had triangles.

If wanted, I can again show the process of how this wallpaper was put together, leave a comment and I’ll write it up.

Which brings me to my second todo which I finally got around to – wallpaper downloads! We’ve already had 9 wallpapers for the Plasma 5 series, and you can now visit to download each of them. For Nuno’s original “Next” wallpaper, I’ve provided a “remastered” version for 4k monitors named “Prev”. It’s not perfectly accurate, but for those who liked the original it is available;


Additionally, there’s a new wallpaper named “History” for those who want to celebrate 10 iterations of Plasma 5 and the upcoming 11th iteration;


(Clicking on any of the images will take you to the relevant page on the KDE Store)

Lastly, much work as been done on the KDE website redesign. I’ll be blogging about it later, but here’s a screenshot showing the general design for the new homepage:

(sorry if the image is a bit fuzzy)


The 2017 Plasma Sprint is sponsored by Meat Water.

A Link to the Tileset & Sprite Trivia

In my off time I’ve been closely examining the Legend of Zelda Link to the Past tilesets and sprites, and I’ve been learning a huge amount about how that game is assembled visually. it’s amazing how much they managed to do with the limited resources of the SNES.

For a game I’ve played religiously as a child, it’s interesting to see the imperfections which I completely glossed over even after several complete playthoroughs. There’s also some neat workarounds Nintendo did while preparing their graphics.

So here’s some “trivia” I found while closely examining the various maps and shots of the game;

  • Bricks lining the floors of diagonal walls are always rounded. This is not decorative, but a limit of their sprite-sheets 8×8 tile resolution. There are 5 unique 8×8 tiles used to create a diagonal wall, it would have required 6 tiles to add the 3 pixels needed to straighten the edge, and another 16×16 composite tile. Same, apparently, with the bottom of diagonal cliff edges. If they fixed this, several tight diagonal corridors would have been impossible.
  • In the overworld you will never find a flower that is NOT above a sprig of grass. You will always find flowers tiled with grass, or above and to the left of two sprigs. If you see three flowers, it’s just a combination of the other two patterns.
  • Live grass and dead grass never touch. I’m guessing because dead grass is a palette swap, so they would have had to include a tile-set for those edges. Instead, there’s always a dirt buffer or a cliff.
  • Bobbing flowers in the overworld have more frames of animation than any single enemy walk cycle. As a matter of fact, some enemies only appear to have one frame in their walk cycles – it’s just flipped to create the illusion of movement.
  • The animation used for guards falling off an edge contains more frames of animation than several enemies have for all their animations, total.
  • There is one tree in the game with a root placed on dirt/cliff edge. The tiles that make up that root are recoloured grass; because of that, one of the colours is slightly mismatched.
  • Cliffs are by far the most complex tiles in the game, but also tend to show the most seams between tiles. To say it must have been painstaking I think would be an understatement.
  • Most dungeons and houses share the same brick walls, only palette swapped with different tops. Instead, dungeons distinguish themselves with unique entrances, pillars, and decorations. There’s also a unique entrance for the monastery which was unused, possibly to avoid it being confused with dungeons.
  • Walls in houses and dungeons also don’t obey perspective, various tricks are used to maintain the illusion. The southmost walls are sometimes outright covered, and very seldomly will you see half-walls or “tall” objects touching the south walls.
  • Braziers, tall lampposts, half-walls, and various other doodads to not contain transparency keys. While not surprising on its own, it’s shocking to realise how many things don’t actually have “shapes” or “blend in” to their environments when closely examined, simply having grey backgrounds which most people must never notice. Those moving spike traps? Those are square, you just thought they were pointy.

Anyway, those were some fun facts.

Zelda: A Link to the Past is simply an amazing piece of work, and the tilesets are remarkably compressed for what they were able to create; PNG images containing the complete light world are larger than the entire game itself, not including the alternate dark world, insides of houses, or dungeons.

Tomorrow is a New Day – Joining Blue Systems

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!

DWD Structured @ CERN


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.


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



Touchdown on CERN: Planning to Plan

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