Since this is related, I'll just drop my concept design for Colours KCM for reference on a possible colour schemes header design to consider. Ignore the button at the bottom, I've realised now that that idea is pointless since we removed so many colour schemes by now out of the box that having a separate page for all the colour schemes is no longer a pointful idea.

Technical Explanation, again:

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. Pretend the bottom 'Colour Scheme' box is all of the current Colours KCM contents
6. Ignore "Use a custom colour scheme..." - that's a scrapped design idea now I've realised we've removed so many colour schemes by default that it's no longer necessary.
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).

Oh, and also maybe put the checkbox you've implemented below that 'Custom Accent Colour...' button if you do implement this design - checking it'll insensitive the button and the accent colour circles.

Looks like plasma doesn't respect the accent color.

This doesn't compile for me:

/home/nate/kde/src/plasma-desktop/kcms/colors/editor/scmeditorcolors.cpp: In member function ‘void SchemeEditorColors::updateColorSchemes()’:
/home/nate/kde/src/plasma-desktop/kcms/colors/editor/scmeditorcolors.cpp:378:16: error: ‘class KColorScheme’ has no member named ‘dropAccentColors’
  378 |         scheme.dropAccentColors();
      |                ^~~~~~~~~~~~~~~~

Also in terms of the UI, I might recommend using radio buttons, sort of like this:

Accent color: (o) Let the active color scheme choose
              ( ) Custom color: [ color chooser button ]

This makes the two states clearer IMO. Also it might be good to put whatever UI we use below the color scheme chooser grid, since the accent color is a subordinate setting.

In D27271#643189, @ngraham wrote:

This doesn't compile for me:

/home/nate/kde/src/plasma-desktop/kcms/colors/editor/scmeditorcolors.cpp: In member function ‘void SchemeEditorColors::updateColorSchemes()’:
/home/nate/kde/src/plasma-desktop/kcms/colors/editor/scmeditorcolors.cpp:378:16: error: ‘class KColorScheme’ has no member named ‘dropAccentColors’
  378 |         scheme.dropAccentColors();
      |                ^~~~~~~~~~~~~~~~

You need the patch this patch depends on, D27263.

Also in terms of the UI, I might recommend using radio buttons, sort of like this:

Accent color: (o) Let the active color scheme choose
              ( ) Custom color: [ color chooser button ]

This makes the two states clearer IMO. Also it might be good to put whatever UI we use below the color scheme chooser grid, since the accent color is a subordinate setting.

👍

Whoops, my bad.

Tested this and found that setting an accept color seems to work for apps and Plasma (yay), but unsetting it doesn't go back to the color-scheme-provided one.

Ping.

These new properties can be managed by KConfig.
It will automatically handle the read/write process and isSaveNeeded/isDefault status.

Could you move this and the dependent patches to Gitlab? It would be good to get this in for 5.21.

In D27271#676512, @ngraham wrote:

Could you move this and the dependent patches to Gitlab? It would be good to get this in for 5.21.

Sure

oooh man, this'll be a doozy to rebase :D