Table of Contents
I hadn't talked about this yet, but there has been work going on behind the scenes to completely revamp the KDE theming system.
In this article I will cover how this new amazing setup works, and it does already work(-ish), plus what the future of KDE styles and themes could look like; but first, this will mean nothing to you if I don't tell you why is this even necessary, what's wrong with our current setup.
Our current setup is sort of a mess.
The Issue
Firstly, we have Plasma Styles. These only apply to Plasma, your shell, and everything else completely ignores it.
They are implemented via SVG files, which have benefits and drawbacks. Mostly drawbacks. Sure, they might be very easy to make, lots of people know how to use SVG, but they are very hard to maintain, they not very fast - because you have to render out entire images - and there's no easy way to expose configuration options.
Which is why you will see the SVGs to be full of these little colorful blocks that are not actually displayed anywhere, but the parser checks whether they exist or not to know whether to turn on and off a certain flag. It's a bit hacky and overall I don't like it.
Fair enough. But this is purely for Plasma. What about other themes?
Well, next up we have Application Styles. They are directly used by all QtWidget applications, which is the type of UI toolkit used by apps such as Dolphin and Gwenview. As you can see in the screenshot, there's no download button.
That's because Application Styles are written in C++ and have to be compiled to be used. The only way to get them is either by, well, compiling them yourself, or if they're shipped in your preferred package manager. On top of that, they're extremely, extremely difficult to make. There are a few third party projects out there who try to branch off Breeze, but starting from scratch is not something you can just do.
Which is why a lot of unixporn users use something called Kvantum.
Kvantum is an Application Style which - to put it very simply - converts a SVG file to a style. Basically, it draws an SVG on the screen. You're again missing out on performance by choosing this, but it does make it much, much easier to create custom Application styles.
But then we have QtQuick Control styles. Many KDE applications, like Discover, are not written in QtWidgets, but in QML, a markup language that has its own style. (Of course it has).
To repeat: Application Styles, which are actually called QStyles, apply on QWidget applications; whereas QtQuick Control styles apply to QML applications.
Well, in order to simplify this whole thing, KDE developed a QtQuick Control style called "Desktop", which uses - bear with me - the QStyle to draw the QtQuick Control style; basically, it uses the same stile that QWidget applications use, but it applies it to QML applications.
This way, if you select "MS Windows 9x" as your Application Style, all of your KDE applications will use it, regardless of whether they are QtQuick or QWidget ones.
But this is also hack-ish. It does not work very well; a lot of the UI of QML applications still does not really follow the QtQuick style at all. This is especially noticeable if you use Kvantum; you will really notice how QML apps stick out in a bad way.
But there's worse (yes, there is). If you decide to switch to Plasma Mobile, you'll find out that mobile applications do not follow the QStyle, but they have their own QtQuick style, written by scratch, and ends up being inconsistent with the other themes.
Why did we do this? Well - hear me out - the QStyle is software rendered, whereas QtQuick supports hardware acceleration, meaning the former won't be as performant on a mobile phone.
So, this is the situation. We have three different type of styles (Plasma, QtWidgets, QtQuick), the third of which is inherited by the second one, and the first two are made in completely different ways, and they don't talk to each other…
But wait, there's worse. There's actually a fifth implementation of the Breeze style, and that's the Breeze theme for GTK. This last one is a GTK theme which tries to resemble Breeze as much as possible, and it's sort of going unmaintained.
So, if anybody wanted to create a new KDE theme, it would probably take a good year of development to write it from scratch. Which is not ideal.
It's also an issue for us KDE developers. It means implementing new style changes multiple times over, and if we want to change something in the Application Style then we need to wait years - yes, years - until someone with a deep knowledge of how they work has some time to work on that.
Union
Luckily, Arjen has the solution, and it's called Union.
The core idea is to have an abstraction over the types of style inputs and outputs. I could give Union a SVG theme, or maybe a CSS theme, or maybe a QML theme, or more; all of those input types would then be converted to the same abstract theme type. Union will then implement various theme outputs, such as QtWidgets and QtQuick, which would just read that abstract theme to know what to draw.
So, potentially you could write QtQuick theme using SVG, or a QtWidget one using CSS, or any other combination that you'd like. Any input can be converted to any output.
Of course, you wouldn't have the full range of SVG options, or CSS options; it would still be a subset of the functionalities of those markup languages, the subset that we can actually translate to the middle abstract layer.
So how do we do this?
And by "we", right now I mean Arjen, but it's soon going to be a more collaborative thing.
He decided to start off with just one input and just one output, understandably. He chose for SVG files to be used as inputs - since we have a lot of Plasma Themes already - and QtQuick to be used as outputs - since it's used by Plasma and many KDE applications.
Union currently does not implement the full QtQuick Style, but it does style most of the basic controls, which allows application to run using it already.
And here we have it. This is Discover styled using the current state of Union. It does not look exciting, but do remember that it uses a completely new theme engine to display … all of this. It is exciting.
The intermediate layer is made of a bunch of "Style Rules", which are created by the input layer (currently, only SVG). They're "which properties do apply to this element", they have a selector which determines the elements that the style rule is applied to. This is quite similar to CSS: you could have a style rule that says "my text should be red", and a selector that says "any focused button".
Oh and – as a Plasma developer, this would also solve my issue of the annoying SVG hint items, since the SVG input layer also accepts a YAML file that actually defines which element is used for which control and, most likely, we can also define things like flags and margins using that same file.
So, what's next?
The current goal, according to Arjen, is to finish up the SVG-to-QtQuick workflow so that we can actually start using Union just for Plasmashell, deprecating the current Plasma Theme implementation; to the user, this should mean that nothing changes at all, but we would start getting real-word usage of Union.
Once we do have real world usage of Union, work could start to implement a QStyle that uses it, which - due to QStyle complexity - is going to be a tough task to handle.
And then, one day it would be nice to have a CSS input, but there's a significant issue; to quote Arjen, "there's no good CSS parser on the internet". What we need here is one that is available as a C++ library and that returns a parsed tree of what's in the CSS file.
If this works, more outputs could slowly roll out; the GTK Breeze theme, which is currently a bunch of manually written CSS, could become just another Union output that we could use.
Even better, this would make it much easier for KDE designer to improve and maybe create new themes; which brings me to another major topic, which is an initiative - driven forward by Anditosan - called Plasma Next.
Plasma Next
Firstly, credit where it's due, you should all go watch Andy's youtube channel, which has frequent updates on his work to improve the KDE Design System. A lot of information on this section was taken from him, and links are in the video description, so go give him some love.
Andy is trying to completely revamp the KDE Design System, which does not necessarily mean a complete redesign of Breeze, but rather a new way to handle its design. He has formed a team and the name of this effort is Plasma Next.
Firstly, there's the question on what to use to do KDE design. So far, we've never had an agreed-upon preferred platform; some of us were doing mockups in Inkscape, but the real designers were just using Figma, which has its own issues… like being proprietary.
The free and open source alternative to Figma is called Penpot. We, the KDE Visual Design team, did watch this new tool be announced and grow, and we were sort-of waiting for it to be good enough for us to use. Penpot very kindly reached out to us, and asked what they could do to help us switch to them.
The design system should have icons, colors, typography, and re-usable assets of the common KDE components, all with the same consistent Breeze branding on them. Currently, Penpot does not support all of the features required for those elements (apparently, icons were already a bit of an issue), but the team has acknowledged that, and they are trying to work to improve those aspects.
Even better, according to Andy, Penpot has provided the Plasma Next team with free training on how to use the tool, and they've joined the Next chat to help out where they can, which is amazing; we really have to thank them for their effort here.
So far, the team has managed to port colors, shadows, typography, and blurs.
Until then, there's a lot of work undergoing to revamp KDE icons over Figma. There's a whole new set of 24px set, new weather icons, and more. There's now work to revamp the 16px icons as well to match the new 24px ones too.
You can see that they're turning out really pretty, with nice rounded borders and a Breeze feel. Of course, since these are drawn at 16px, they won't look this good on an actual screen, but still. Pretty good.
And, as I mentioned above, in the past months a consistent set of Plasma colors was created, along with some standard shadows and blurs to use on any element. Apparently there's some sort of token mechanism to categorize the various colors, but really you should just read Andy's blogpost about it if you want to get technical.
Of course, this is not something that has an immediate payoff, and the same applies to Union. But it's great to see that we, as KDE, but not me specifically, other people, are able to address those long-term tasks that will make the project best-in-class over its design department.
