Accent Colors, Color Ramps and other improvements to theming.
Open, Needs TriagePublic

Description

Goal:
Design an accent color system and related components for the Plasma desktop and reiterate on the Appearance/Colors UX.

Motivation:
While Plasma makes it possible to change the color scheme, it's not presented in the most accessible way. Especially compared to how easy some other OSes make it to easily change the accent color.

Prior Art:
kcm-colorful:

Windows:




OSX:


Zorin OS:

AlphaBlack Control:

@Zren explained how AlphaBlack Control could be adapted in this comment:

In T8755#186648, @Zren wrote:

The widget basically switches to breeze-dark by editing ~/.config/plasmarc, waits a few seconds, then switches back to breeze-alphablack.

https://github.com/Zren/breeze-alphablack/blob/master/desktoptheme.py#L176

Ideally, a dbus signal would be created to force the current desktop theme to reload without needing to switch to a 2nd theme. You'd have to make sure it notify's plasmashell, krunner, latte-dock, etc as they all use plasma theme SVGs. We need the QML Plasma SVG to re-generate the stylesheet injected into the SVG.

To have a separate accent color for the panel we would need to create a new desktop theme in ~/.local/share/plasma/desktoptheme/. We'd need to first create:

  • .../desktoptheme/BreezeCustom/metadata.desktop which should inherit default, just like like Breeze Dark.
  • .../desktoptheme/BreezeCustom/colors which is generated from our accent color.

    Then switch to BreezeCustom if we're not already using it.

Worth looking into:
This article Designing Systematic Colors (and comment) explores some of the challenges with generating related colors. I'll include an example of some color ramps which are generated from one color each, along with some information about the colors including their accessibility ratings according to the WCAG standard.

There is also this implementation of the algorithm based on the aforementioned article:

Also interesting is Adobe Color:

and IRIX Web Tools / Iris:

We've been discussing this in some recent tasks (T10046, T8755) so I thought I would just open up the discussion.

+1, I think this "accent color" thing is a nice UX improvement, and basically everyone else already has it. We have all the necessary backend support ready to go via the color scheme's "highlight" color; we'd just need to add this as a new UI element on the colors KCM.

Don't forget to add VDG as a subscriber or else nobody will see it (Phab doesn't send notifications for tags on tasks, only subscribers).

ndavis added a subscriber: ndavis.Jun 10 2019, 10:51 PM
mglb added a subscriber: mglb.Jun 10 2019, 10:54 PM

Yes yes yes!

HSLuv (optionally with a ramp) works nicely for things like this. I'm using it in reimplementation of Konsole's "random background" feature (WIP: D20263, stalled a bit for now).

lavender updated the task description. (Show Details)Jul 16 2019, 3:51 PM

@mglb maybe the konsole code could be adapted to kcm-colorful? It has a lot of the features we want

mglb added a comment.Aug 2 2019, 2:32 PM

@mglb maybe the konsole code could be adapted to kcm-colorful? It has a lot of the features we want

hsluv has an external lib (actually used in mentioned Konsole diff), it would be easy to use.

At its simplest, it'd probably look like this (but way less bad), however it would be nice if it had a tickbox directly above it for enabling desktop background dependant colouring instead and maybe also have a bunch more colour options. Max cap, I suggest, for custom colours would be 30 custom colours, with every new colour made after that point causing the custom colours to shift backwards once overriding the 1st colour and then the newest one would be on the end of the 30th custom colour.

Some more ideas I'd like to see implemented, when we add accent colours, on the colour scheme creation side:

  • Allow for colour schemes to use the current accent colour as a colour for any colour scheme colour item
  • The 1st one but also allow them to specify brightness on that accent colour, meaning that you can then make things like accent colour tinted colour schemes ala Zorin OS Dark Themes
ndavis added a comment.EditedJan 5 2020, 3:21 AM

I don't see a great benefit to implementing this. While the addition of an accent color feature and an improved color scheme editor are not mutually exclusive, I think that an easier color scheme editor would significantly reduce the need for an accent color feature. This is yet another system on top of the color scheme system, on top of the Qt palette system.

@ndavis by "this" do you mean the whole accent color idea? If so, I don't really agree, sorry. No matter how easy we make it to edit color schemes, doing so will still be a much more heavyweight experience and a less discoverable feature compared to a simple color picker exposed at the top level of the KCM that overrides the color scheme's highlight color. The idea of an accent color feature is basically saying, "this is the color in the current color that the user is most likely to want to change to suit their personal aesthetic preferences, so let's make it really really easy to do so."

ndavis added a comment.Jan 5 2020, 7:15 AM

@ndavis by "this" do you mean the whole accent color idea? If so, I don't really agree, sorry. No matter how easy we make it to edit color schemes, doing so will still be a much more heavyweight experience and a less discoverable feature compared to a simple color picker exposed at the top level of the KCM that overrides the color scheme's highlight color. The idea of an accent color feature is basically saying, "this is the color in the current color that the user is most likely to want to change to suit their personal aesthetic preferences, so let's make it really really easy to do so."

Kind of, but not completely. I'm just wary of making an already complex color system even more complex.

Thinking out loud:

  • Accent color is basically equivalent to QPalette::Highlight, which currently gets its color from Selection Background. This would be pretty simple to use for accent colors, but the existence of FocusColor and HoverColor complicates what could be considered the accent color.
  • FocusColor and HoverColor could be calculated based on the accent color, but the results aren't guaranteed to be nice for accent colors that are too bright, dark or have too low saturation. Perhaps we'd have to make a specialized accent color picker with a limited range of colors?
  • What about theme designers that intended for a specific highlight color to be used? Should the accent color be unset when switching themes?
  • I'm normally against basic/advanced UI splits, but I could see the color scheme editor being a valid place to use that kind of UI split.

Here's a new mockup I did of what the Colours KCM could look like with Accent Colours

Technical explanation:

  1. The #006aff coloured circle at the end is a custom accent colour that the user added themselves
  2. Clicking 'Custom Accent Colour...' will bring up a colour picker popup akin to the KColorSchemeEditor concept one, which'll allow you to make a new Custom Accent Colour. Once created, it'll appear on the end of the bunch of circles next to the existing ones
  3. A maximum limit of custom accent colours will be there, however just like with Windows 10 this won't be 1 custom colour, but rather something like 10 or 20
  4. Once the user adds a new custom accent colour that exceeds the limit, the oldest accent colour is forgotten, the remaining ones pushed back one, and the new accent colour placed at the end each time that happens
  5. The Colour Schemes presented on the bottom could either be colour schemes specified by the distributor in an RC file or 'Pinned Colour Schemes' for quick access (again configurable by the distributor via an RC file)
  6. Clicking "Use a custom colour scheme..." will take you to the current Colours KCM page but as a sub-page, like how "Configure GNOME/GTK Application Style" takes you to the remains of the GTK KCM's page in Application Style KCM
  7. Ignore the lack of icons in this concept - I couldn't bother trying to find them to add them in (I think we all know what icons'd go on what buttons).

That looks almost pretty similar to what I had in mind when I pictured how to implement the UI for this.

It looks like all we need to do is add the accent color UI as a header in the existing Colors KCM. I don't see the value of making that KCM a sub-page when your mockup above shows that essentially already *is* the Colors KCM. Distros already can and do add their own color schemes to the KCM.

The-Feren-OS-Dev added a comment.EditedFeb 9 2020, 2:59 PM

@ngraham The reason for the concept's two-colour-grids is this:
The first page's grid is limited to A FEW colour schemes that the distributor chooses. This can then be used similar to how Zorin Appearance only presents a light and dark option initially to the user before presenting the rest of the themes below that in its dropdown menus. This keeps the user from looking in the haystack of colour schemes on the second page for the distributor's light and dark colour scheme(s).

The second page will be where you can choose ALL of the colour schemes.

If we present only the most important colour schemes initially, and then let the user be subjected to ALL the colour schemes on offer if THEY want to be subjected to it, it'd greatly reduce confusion for certain users as they try and find the light and dark mode colour schemes that the OS is designed with in mind.

That looks almost pretty similar to what I had in mind when I pictured how to implement the UI for this.

It looks like all we need to do is add the accent color UI as a header in the existing Colors KCM. I don't see the value of making that KCM a sub-page when your mockup above shows that essentially already *is* the Colors KCM. Distros already can and do add their own color schemes to the KCM.

@ngraham The reason for the concept's two-colour-grids is this:
The first page's grid is limited to A FEW colour schemes that the distributor chooses.

By default we only ship four color schemes. Distros can add more. So in practice I don't think for most users the grid will confusingly have dozens of things in it. Conceptually, I don't think it makes sense to separate the KCM into separate "curated color schemes live here" and "all color schemes live over there" grids. We don't do this anywhere else.

But this is just bikeshedding, so I'll shut up now. :)

The-Feren-OS-Dev added a comment.EditedFeb 10 2020, 10:00 AM

"By default we only ship four color schemes."
Most distributors of Plasma include those four... and then all the other standard Plasma colour schemes besides that, resulting in a truck load of colour schemes to present users with out of the box. If we have a curated box on the first page the user sees, they'll easily know what the light and dark colour schemes that the distribution is built with are, and won't ever have to be surrounded by the other colour schemes unless they want that much customisation.

As for the we don't have that elsewhere point: To be fair those don't have anywhere near as many items in them to choose from by default, anyway, so the user is never swamped with options galore in the other KCMs out of the box.

"By default we only ship four color schemes."
Most distributors of Plasma include those four... and then all the other standard Plasma colour schemes besides that

Sounds like a packaging problem to me. We should encourage distros to drop the old color schemes like Norway and Honeycomb, which are now available via GHNS.

The-Feren-OS-Dev added a comment.EditedFeb 10 2020, 6:47 PM

Alright, fair enough, I noticed that just now.

While we're at it: There is still one colour scheme that'd probably want debating on the removal of from Colours KCM, though, being:

  • Krita colour schemes - I know they're needed for Krita, but would it be a possibility to hide these from Colours KCM or something unless you user installs them from KDE Store personally? They don't really work as system-wide colour schemes IMHO colours-wise.
mglb removed a subscriber: mglb.Feb 11 2020, 3:07 AM