+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).

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).

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

In T11052#193361, @lavender wrote:

@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

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."

In T11052#216506, @ngraham wrote:

@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.

@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.

In T11052#220349, @ngraham wrote:

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.

In T11052#220382, @The-Feren-OS-Dev wrote:

@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. :)

"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.

In T11052#220475, @The-Feren-OS-Dev wrote:

"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.

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.

I like the overall idea. One thing (maybe even a benefit): I think it would require some more abstraction and maybe simplification of how the current system works (at least from how I think it works). In the future I guess that abstraction and simplification will make changes easier.

Here's an idea, have the standard Breeze colors showing up on the kcm next to all other color schemes installed, and have copies of said standard Breeze with the accent tweaks but hidden, only shown as a button the color of the accent above the list in the kcm.

One problem that came to my mind that I think @ndavis mentioned in a different context is that there might be conflicts with icon colors.

I'm not really convinced by the accent color feature or the way this is currently presented. I fear this will only confuse users since then you will have two ways to edit colors put in the same KCM and in the same view.

What happens if a user selects an accent color and then a color scheme? Does the color scheme overwrite the accent color and in this case is the accent color reset to an initial default "none" value? or is the accent color applied on the selected color scheme and then this breaks the carefully crafted color scheme? Both options sound wrong to me.

I agree that having both options might lead to problems. I think most or all other places where accent colors are used don't offer more detailed color settings. One possible way to circumvent problems would be to show accent colors by default and then have an additional "advanced" menu. Applying accent colors would override all settings in that "advanced" section (after displaying a warning probably). One could click on a blue accent color have that oveall scheme applied. After changing stuff in "advanced" and clicking blue again those things would be overwritten by the default values again.

That would be one solution I think might work. One could also think about simplifying the "advanced" options a bit more.

See https://community.kde.org/Get_Involved/Design/Lessons_Learned about Basic/Advanced mode. The real solution would be to just make the scheme editor easier to use. I saw some nice mockups somewhere.

Not sure if this has been linked yet: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/305

That would be one solution I think might work. One could also think about simplifying the "advanced" options a bit more.

Perhaps the color scheme editor could have the first entry in "Common Colors" be "Accent Color" which would be "Varies" ("Custom" might be better for this special row) if the following colors don't match:

• BackgroundNormal (base color?)
• BackgroundAlternate = BackgroundNormal + rgb(0.1, 0.1, 0.1)
• ... etc

And when you click "Varies" and select a new color, it generates the other colors? Like so:

https://github.com/Zren/breeze-alphablack/blob/a8db5fc833438efcdd90762493f4600c48ab3ba2/desktoptheme.py#L587

@lavender @ngraham @ognarb
Regarding this feature wish https://bugs.kde.org/show_bug.cgi?id=444676
Do you think it is technically "complex" to implement to have wallpaper derived colors as accent color? So that accent colors will change by Activity?
I wrote "complex" because the term has fallen several times here:
https://bugs.kde.org/show_bug.cgi?id=341143

great!