Color themes seem like a brilliant idea until hit the point where your custom control needs this one extra distinct highlight or background color to convey state. Then you're out of luck. You only have bad options left: opt out of system theming and enforce your own or hardcode a color (or put it into the settings dialog) and accept that it breaks with any non-default theme out there because no user will take time to look at the settings and fiddle with the colors. Either way, any usability benefit from good default themes (e.g. high contrast themes) is pretty much gone.
Number two is the enforced theme I was tslking about. Offset colors can be problematic for a number of reasons. The main one is that you don't know if the color that is generated that way has the right amount of contrast to each of the other colors it appears with and that the end result is something that is visually pleasing.
As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that.
But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes.
The biggest issue is that developers don't want to follow gnome checklist. Instead of that, they hardcode colours and behaviour. They go heavy into 'it works for me'. And then have audacity to complain that world doesn't bend to their will.
Here is a gnome checklist. I wish the open letter stated how their application follows the checklist and was broken by a distribution so that the checklist now includes fails.
The way I see it, there are two options here: either require themes to specify colors for many more semantic use cases or give up on themes.
Icon consistency is also just not possible. Any halfway decent application with a properly designed UI will have a set of prominently displayed custon icons for the main commands that make the software what it is. There is no way that these icons can be consistent with whatever random theme you chose to use today.
I have a strong feeling that if custom themes are breaking apps, then those apps are almost certainly in violation of one or more of tables 2-4, 2-5, or 2-6.
Maybe, maybe not. Some apps have no obligation to meet these checklists because they are for tasks that can only be performed by people with no significant visual impairment. I am not claiming that this a common case. But how would e.g. someone with poor eyesight use gimp successfully? Dumb line of business apps that have a simple UI made mostly out of standard widgets have fewer excuses.
There's nothing stopping a graphics toolkit from following the lead of Bootstrap and having N different "semantic tints" with names like "primary", "danger", "done", "busy", "paused", etc.; where the theme designer then gets to define, for their theme, what color "primary" or "danger" will be—but ensures that that color coherently means only that semantic idea throughout the theme. (So if they create a theme where "danger" is blue, then the window close caption-button should have a blue background, the delete-permanently icon should have blue as its primary, etc.)
Then you should fix your app so it can be used by color-blind users. Aside from that, you should use distinguishable background colors A, B and C specified by the system color theme. It's more likely that its designer has considered accessibility issues than that every single app developer has.
Have you looked at the set of colors that is actually defined by a theme? That is my point: I would use these colors gladly if they were there. They aren't.
If you're reliant on color to convey critical information, then your app is by default already much harder to use for colorblind users. Anyone who feels one needs these extra specific colors really ought to rethink the core design.
