Bug 452510

Allowing those things to be explicitly stated into the color schemes would allow a great deal of simplification and versatility, could improve the user experience, and in the future would prevent headaches. 

As things are, the current and future new implementations of the Accent Color is by forcing it on the color schemes, and that assumes what works for Breeze will work for every Color Scheme, which isn't the case. An example of this is "Leaf", it's a subdued color scheme, and due to this most of the default Accent Colors are simply too vibrant for it and look out of place. This issue could be mitigated if the author could state in the color scheme to mix the accent color with some type of gray, or better yet: Mixing it black, but specifying by how much. 

Most color schemes repeat the same colors, Breeze for example has many lines with the same value. If it was possible to use variables and/or reference the values of the previous lines, it would simplify changing them, as changing the "parent" would also change all the others that reference it. You can edit the color scheme with in System Settings, but it is frustrating to replace one color as you need to figure out in the GUI every other element that uses the same color. At that point it is easier to use a text editor, but you lose the visual feedback of changing it through System Settings.

If you could reference and use variables for colors, the Color Editor would only need to show the unique colors. Windows 7 allowed users to change the color of the title bar, task bar, as well as other things, by using a simple color selector. It really was simple to edit the visual of the system by just changing one thing. The use of Variables would allow something similar in KDE without the user needing to edit everything else.

Conditions could be set for specific edge cases to improve readability, to deal with users changing the variables, by improving contrast, for example: If a specific color is closer to White than to Black, it could be mixed with black, but not do anything if it is closer to black. This could even so far as to allow Dark and Light mode on the same color scheme, without requiring duplication of the color scheme if the creator is smart enough.

This wouldn't be a silver bullet, but would simplify and allow versatility for the Color Scheme Creators, and would make it far easier to implement dynamic colors for breeze without writing code to force it into existing color schemes. There is always the potential that the Accent Color would look great in a specific place on a color scheme, but it would look awful in the same place on Breeze, the inverse is also true. The current implementation of the Accent Color AFAIK don't allow flexibility when it comes to using it. This would "fix" it, while also opening the door for other possibilities in the future.

If you are familiar with the Kustom suite(KLWP, KWGT and KLCK) of Android Apps, this proposal is inspired by what can be done with that.