[kde] [Bug 452510] New: Allow ColorSchemes to use variables, conditions and mixing colors

WS bugzilla_noreply at kde.org
Mon Apr 11 18:32:54 BST 2022


https://bugs.kde.org/show_bug.cgi?id=452510

            Bug ID: 452510
           Summary: Allow ColorSchemes to use variables, conditions and
                    mixing colors
           Product: kde
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: unassigned-bugs at kde.org
          Reporter: ws.kde at outlook.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Unassigned-bugs mailing list