Some time ago I started Krita and I had the thought: well we can do better. The window decoration is just looking out of place. Everything is a nice dark color, but the window decoration isn’t. So I asked a few people what they think about making it better and the reaction was overall very positive and I started to investigate.
Right now I have a solution for KWin/5 which allows the window decoration to follow the color scheme of the window. Have a video:
At the moment it’s implemented mostly inside Oxygen, but I intend to move most of it to KColorScheme an KStyle directly, so that any KDE/Qt application can benefit from this new feature.
And of course I need to point out that all of that is possible without opening Pandora’s box of Client Side Window Decorations as Aaron said today.
This looks AWESOME!!!
Could you please explain a little bit how this is implemented? And what need to be done in a decoration theme in order to support this. AFAIK, QtCurve theme sets the background color/opacity and other stuff as x11 attribute which can be read by the decoration theme to change how the decoration is drawn, is this implemented in a similar way?
P.S. the links in email feed are still broken.
yes it’s also based on x11 properties on the window. The theme does not have to do much. A new
QPalette KDecoration::palette()
method got introduced, so the decoration just needs to change to use this QPalette instead of the one in qApp.
Hello, what distro do you use? Thanks dude thanks friend
I’m using Debian testing, but all KDE software is self-compiled.
Oh… Now I understand everything. It’s hard to do it? Because I love Debian but is a **** to have old versions of KDE software :/
Hard to do what? What Martin blogged about here?
This is programming, has nothing to do with Debian or any other distribution. He could do this on any distribution and the effort would be the same. He didn’t install the software, he wrote it himself…
Is this possible for KDE Workspaces 4? I know about the feature freeze, but as you reported in G+ this feature is small, and it should be regression-free, so an exemption case could be made.
No, I do not intend to backport this to KDE Workspaces 4. The main reason is that the changes to KWin are rather large and make use of all the new code magic we got with Qt 5 and C++11 😉 So it would only be useful for having kdelibs4 apps running against Plasma 2. And for that I don’t think it’s a good idea to break the feature freeze. After all the applications can also use it in their own code directly if they want.
Great work. Maybe this could be the first step towards system-wide themes 🙂
Wow! I like how by switching the color scheme as soon as a scheme is clicked on you have greatly simplified the KCM. But will these KCM’s be necessarily with Plasma 2 “Loolk and feel” packages Aaron blogged about (since KWin is part of the Workspace) or do these packages only affect Plasma 2?
This is not a KCM which you see there. It’s the minimum code needed to get different colors.
I would like the apps run by “root” to also inherit the current user colors – is this possible? Maybe KWin could give some hint by itself that the app is run by root.
running apps as root is wrong in the first place 🙂 Because of that I am not interested in adding anything to KWin to make that better.
Well, generally I agree abut what about Krusader in root mode for file management? or Yast in openSUSE for system configuration? Actually GUI package installation often calls apps as root. If you install a new package in openSUSE the colors of the GUI will not be consistent with what the user has set. The workaround is to run systemsettings as root and set a color scheme there, but in my opinion this workaround should not be required. 😉 Regardless of whether it is wise to run Qt apps as root at least openSUSE does so anyway, and perhaps other distros as well. For some reason kde provides “kdesu” so maybe it is not as EVIL as one might think. 😉
there is no reason to have a file manager run as root. If it needs higher privileges it should use policykit. Same for YAST and I haven’t seen a package installation which doesn’t use policykit for years.