Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.
Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.
What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.
But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.
Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.
But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.
But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.
So we can write themes without the limitations of a theme engine 🙂 This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.
For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.
But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.
I hope to see many innovative QML based window decorations in 4.9.
Hi,
This looks like a promising and indeed love-needing part of the window
management bits in KDE, it would be great if the whole engine would be
just based on QML leaving out the older layers. I’m also wondering if this
would pave the path to get kwin running on Wayland, can you comment on that?
Niels
It does not make much difference whether we base the engine on the old decoration API or not. Some wrapping code is always required and the current way does not introduce too many changes in unrelated code.
This has nothing to do with Wayland. Window decorations have been supported for quite some time in the KWin-Wayland branch.
Wow, is QML that powerful? When I heard of it I thought it was more to do simple things, but render me impressed.
This means, something like that oxygen-appmenu windeco (which I use, although it’s broken without compositing), could be ported to this allowing for “menus-in-a-button”? If that’s so…where can I find code snippets and documentation for QtQuick? 😛
By the way, is this stuff in 4.8, or is planned for 4.9?
The appmenu is something I want to add and yes this is all for 4.9.
I love you. Will be anticipating 4.9 badly, then!
“By the way, is this stuff in 4.8, or is planned for 4.9?”
4.9
Very nice.
In the current version of Aurorae, all decorations have the same layout and this layout can be configured with variables in a rc file.
With Aurorae 3, will the layout be defined in a qml file ?
Will it improve window tab rendering ?
Do you have some code to share ? I would like introduce appmenu support I am currently working on.
No the theme format does not change, it’s backward compatible. But when the plasma package support for QML is added it will be possible to write the complete decoration in QML 🙂
Currently window tabs are removed. But when it is re-added it should be possible to improve it.
Currently on reviewboard. Will be merged into master in the next few days.
That would be nice 🙂 I already thought about it and wanted to add a dedicated QML type for it.
Would porting oxygen to this new architecture be a good idea ? (or at least, a nice example)
no, Oxygen is QWidget based and shares most code with the Oxygen style for QWidgets.
It is possible to create a decoration that looks like oxygen but a good color scheme support for plasma::svg is missing.
I asked the guy who wrote Bispin kde theme how to make kde themes like that and he said its mostly c++. Where’s the documentation on making window decorations? the aurorae tutorial?
http://techbase.kde.org/User:Mgraesslin/Aurorae
Very nice work, as always!
I have a (nooby) question however:
Currently the Aurorae themes (or at least most of them) are very badly behaving in a non-composited environment. For example translucency isn’t working and the shadows/borders are just replaced by an ugly squared bold black border but overall they seem completely bugged if composite is off. I guess it’s because they haven’t been designed for non-composited desktop. Then would this QML port make them more useable and better-looking in a non-composited desktop (just like Oxygen?) ?
I know now, thanks to the all the compositing improvements you have made in Kwin, that compositing is “cheap” and useable on most of cases and even tho I have a very decent hardware I still have to turn it off sometimes to play games, it’s just too bad the aurorae decorations go crazy when I do it.
Aurorae supports non-composited modes. Unfortunately hardly any theme made use of this capability. Because of that I decided that it is not worth to continue to support Aurorae for non-composited setups. I will try to fallback to Oxygen if compositing is not active.
This is 4.9 material, sure. But there is something that could be done in the 4.8 framework, and this is: please, update the current Aurorae themes in kde-artwork, or delete them. They are broken, if I try to apply them results are horrible, and what’s even sadder: sometimes there are updates, for those themes, in kde-look.org, and I can’t delete those broken themes.
So, for 4.8, can you go shopping through KDE-Look, update the Aurorae themes with new ones, delete those broken themes and leave only working themes for release?
Cool stuff Martin!
I know this may not be your area Martin, but do you know of any longer term plans for QWidget based UI versus QML based UI for KDE desktop as a whole?
With Plasma Active using mostly QML for some of its application UIs and the potential for some of that great work to end up in plasma-desktop, there seems to be a pretty sharp break between the traditional QWidget based applications and QML based apps. It seemed that one of the original design goals of oxygen was to have a seemless transition between window decoration and app. I’m not sure how such design goals will be supported in the longer term. Originally there was meant to be a distinction between the desktop and the applications, that I’m less clear if that is still a goal and how it will be supported. Also, there’s a lot of useful infrastructure built up around QWidget (styles, color palettes, etc.) that I’m not sure how to plan for in the new QML world.
To be clear, I’m not objecting to any particular direction. I mostly interested in what that direction is. 🙂
im already excited for 4.8 to hit stable. Now I cant wait for 4.9.
thats what i think about every release of kde since 4.0
will the arurorae desiner still work?
http://kde-apps.org/content/show.php/AuroraeDesigner?content=122763
Yes, but it might offer functionality currently unsupported by Aurorae (e.g. Tabs)
This truly is just awesome.
However, a question related to the appmenu and the window menubar.. Imagine that someone adds the appmenu, would he also be in control of the default state of the menubar? Since i kinda think that the window menu bar should be hidden (by default) if the appmenu is defined. What’s the point in having 2 menu’s 😉
Hey, cool stuff.
Is this decorator able to scale the decoration? So that I can use maybe a 25-pixel-high decoration normally, but a 75-pixel-hight decoration when I use it on a TV monitor and I’m sitting far away from this monitor?
I think that it is important to be scalable today. New form factory are showing up, first HD devices come …
you can just use a bigger border. But I do not really see what the advantage is of huge decorations when the window itself is not scaled up.
Well, you can scale up the window itself. This is still some work by hand, but it works. You can raise the Font DPI, which makes fonts display bigger. If you use a scalable widget theme (for example: Skulpture) than the widgets itself are also raised. And there is even some discussion about making the Oxygen widget theme scalable. And with KDE 4.8 you can also use pseudo-scalable cursors.
So I think this is a quite important tecnologie for the future, as computers with different form factors show up. I was using KDE on a TV monitor (just to play films). And I’ve used a hight Font DPI and Skulpture (because I’m sitting far away from the screen). It works more or less, but there is still much to do until scaling works good. So I think it would be a good idea to include this posibility and to have this in place for KDE 5 …
Hi Martin ! First, thanks A LOT for your great work and commitment.
Here is partly an off-topic comment (but partly not :). I’m one who those who have been (gently) complaning about the kwin performance for months / years. Especially, for some reasons, since 4.7.
I just figured out the culprit after years of tweaking xorg, kwin, drivers (nvidia), distros etc.:
–> the Oxygen windows decorations animations.
By disabling them kwin animations become butter smooth again. (you know, the windows borders animations)
Not sure where to file this bug, though.
Cheers & thanks again !!!!
It is off-topic and no news at all to me. In fact I dedicated this an own section in Desktop Effects Performance
Yep, indeed, I realized this meanwhile 🙂
Sorry for the noise ! (I thought it was a little relevant as we were talking about decorations 😉
Actually, I’ve been struggling for a LONG time with this, and I just realized many people were suffering from it too. As I never found the solution in the past 2 years, I thought I had found something new 😉
Anyway : sorry again 🙂 Cheers !
since this post is about aurorae and i have found nothing constructive on this topic i’ll ask here..
i experience very bad lags when using any aurorae theme.. kwin with oxygen is really fast but the moment i switch the window decoration to aurorae its over..
can you point me to the right direction (url) to learn more about a solution or isn’t there any for nvidia users?
thx in advance!
In general: for support use http://forum.kde.org
and don’t forget to check the Wiki: http://userbase.kde.org/Desktop_Effects_Performance
thx.. i tried everything on that list except kwin_gles –replace .. no wait.. i also tried this one but it does not support any effects ??!!
i’ll ask at forum.kde.org and meanwhile use oxygen window decorations since aurorae has this performance issues on my machine.. beside.. kubuntu 12.04 with kde 4.8 is really realy fast now. thx for speeding it up a little with every single release