The "Titlebar color scheme" window rule is not accounted for Aurorae themes. Whereas builtin themes such as Oxigen or Breeze respect this setting, color themes based on Aurorae do not and maintain their normal appearance despite the override. Reproducible: Always Steps to Reproduce: 1. Go to Configure Desktop - Window Management - Window Rules, click the New... button. 2. Under Appearance & Fixes, enable Titlebar Color Scheme, set the effect to Force, and select any scheme that has a different background and titlebar from the normal scheme. 3. Apply the rule and open any affected application. Actual Results: If you're using an Aurorae theme with colorization support, this rule will have no effect. Expected Results: The rule should be respected for Aurorae themes, just as it's respected for the builtin Breeze or Oxygen themes. Can be easily tested with one of the following themes... which use the window background color for the titlebar just like Oxygen, as well as colorized button effects: https://www.kde-look.org/p/1002614/ https://www.kde-look.org/p/1002663/
Problem still present in Plasma 5.8.0.
Did anyone get to take a look at this so far? The problem does throw a wrench in some elements of system customization, as it makes the feature unusable with the theme I currently have.
In general in case of Aurorae color scheme support does not make much sense as most themes are well themes and the design of the theme is what matters most. Supporting color schemes from the window is not directly in the focus of Aurorae. It can be done, but it just isn't anywhere on the priority list of the core development team. Of course everybody is encouraged to get their hands dirty and to provide a patch.
Still a problem in Plasma 5.9.0. I would be happy if any of the developers could please offer more insight on this, and add the problem somewhere on their list. (In reply to Martin Gräßlin from comment #3) I don't agree that this is less of a priority with Aurorae, compared to any other theme engine. While it's true there are fewer Aurorae themes with support for scheme colorization, this is missing functionality in one of the official KWin theme engines.
> I would be happy if any of the developers could please offer more insight on this Well the problem is that Aurorae is SVG files. We cannot just color that. For the QML based themes that should be a non-issue anyway as the color scheme should be available to QML anyway. > and add the problem somewhere on their list. I'm sorry, it's very unlikely that this will get any priority as it just doesn't match how Aurorae was designed. > I don't agree that this is less of a priority with Aurorae, compared to any other theme engine. As I am pretty much the only developer and inventor of Aurorae, I think I'm qualified to say what fits into the design of Aurorae as it was planned and what not. The main idea behind Aurorae was giving designers the possibility to design a theme just as they want it.
(In reply to Martin Gräßlin from comment #5) Sorry about that, I wasn't aware you are the maintainer of Aurorae. Definitely taking your point as an official stance then. The reason I consider this strange is that svg elements can already be colorized, which is how my themes work. The colorization simply doesn't happen when a window rule sets it, although it does work when the global color scheme is changed. I assumed that was just the window rule forgetting to notify KWin about the color in the same way the main color scheme does, but of course I don't know the code and if there's more involved. Is there a fundamental difference between how the two work, that's getting in the way of a fix? If the purpose of Aurorae is letting artists create themes the way they like however, I do think this should be considered; The themes I made and listed in the description were intended precisely to work with color scheme, and let people play around with system colors in any way KDE lets them. Per-application color sets are something I looked into for this very reason, until the ability to force colors with window rules was recently implemented... which I hoped would offer a way to do things like the random titlebar colors seen in Windows 10, until I noticed this limitation once I tried. I think it should also be kept in mind that to the end user who's using such themes, the appearance window rule not working seems like a bug. My thoughts when I noticed this were "it works with the Breeze theme, it works with Oxygen, it only doesn't work with Aurorae... clearly there's a problem with it". To someone who knows the code and initial purpose it might be different, but to my untrained eye it's an incomplete new feature and among the lines of "when I select both X and Y, Z stops working". Hopefully this offers more insight on why I'm suggesting this. I'll leave the report open personally, since I'm hoping a solution isn't entirely out the window either and you might come back to it at some point... you know best though.
*** This bug has been marked as a duplicate of bug 345007 ***