Hmm, this doesn't seem to work for me.

In D24122#535474, @ngraham wrote:

Hmm, this doesn't seem to work for me.

Could you elaborate?

Window decoration buttions in Chromium with CSDs and the Breeze Light color scheme don't show any difference with the patch applied and deployed.

In D24122#535486, @ngraham wrote:

Window decoration buttions in Chromium with CSDs and the Breeze Light color scheme don't show any difference with the patch applied and deployed.

This isn't elegant, but it's because of an upstream Chromium bug not allowing recolorable window buttons without issues.
You have to set the GTK theme to the newly generated Breeze Light, not just the color scheme. This is being added to give users a workaround
before upstream bugs get fixed and a version with those bugfixes is released.

(BTW It would be nice if that information were spelled out clearly in the Test Plan section :) )

Oh, gross. Better than nothing I guess, if it's impossible to fix the bug any other way. On the other hand, this feels like it kind of partially defeats the point of making the Breeze GTK theme respect the system's color scheme if we're going to generate multiple versions of it specific to different color schemes. Is there really no other way? Is there an upstream Chromium bug report tracking this on their side?

In D24122#535494, @ngraham wrote:

(BTW It would be nice if that information were spelled out clearly in the Test Plan section :) )

Oh, gross. Better than nothing I guess, if it's impossible to fix the bug any other way. On the other hand, this feels like it kind of partially defeats the point of making the Breeze GTK theme respect the system's color scheme if we're going to generate multiple versions of it specific to different color schemes. Is there really no other way? Is there an upstream Chromium bug report tracking this on their side?

Yeah, there's not really any other way unless you're okay with duplicated, stacked window buttons of different sizes and colors on top of each other. Chromium just doesn't simply separate the CSS nodes necessary to do recolouration without visual glitches. (Mutter when drawing SSDs has the same issue, actually)

I'll file one tonight, since you reminded me that I didn't do that.

Yeah, please do file a bug on Chromium.

I'm hesitant to approve this because once we create a "Breeze Light" GTK theme, will we actually be able to remove it? Also, is the number of people who know that you'll need to use this new GTK theme to solve that specific Chromium bug likely to ever be larger than the set of people who wrote or reviewed this patch? :)

Filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1006573

We got another bug report illustrating another reason why this might be desirable from a user perspective, aside from the Chromium bug: https://bugs.kde.org/show_bug.cgi?id=413111

I'll rescind my objection so we can review and get it in. Can you rebase the patch?

In D24122#561710, @ngraham wrote:

We got another bug report illustrating another reason why this might be desirable from a user perspective, aside from the Chromium bug: https://bugs.kde.org/show_bug.cgi?id=413111

I'll rescind my objection so we can review and get it in. Can you rebase the patch?

This patch isn't going to fulfill that feature request. The only result is the generation of non-recolourable assets at build time, not that the theme blocks recolouration.

I thought this patch results in a "Breeze light" theme becoming visible in the KCM. If so, that would seem to fulfill the request, unless I'm misunderstanding how the Breeze Dark and proposed Breeze Light themes work. If these themes don't have hardcoded colors (as opposed to theme-respecting colors), what's the difference between them and the "Breeze" theme?

In D24122#561739, @ngraham wrote:

I thought this patch results in a "Breeze light" theme becoming visible in the KCM. If so, that would seem to fulfill the request, unless I'm misunderstanding how the Breeze Dark and proposed Breeze Light themes work. If these themes don't have hardcoded colors (as opposed to theme-respecting colors), what's the difference between them and the "Breeze" theme?

The difference is in the generated png assets that can't be recoloured. Currently, this is the checkboxes (due to librsvg bug), and the window buttons used by Chromium (due to chromium bug).

Could we repurpose the Breeze Light and Breeze Dark GTK themes to simply hardcode everything to be dark or light rather than following the color scheme? That mirrors what we do for the Plasma theme.

In D24122#561761, @ngraham wrote:

Could we repurpose the Breeze Light and Breeze Dark GTK themes to simply hardcode everything to be dark or light rather than following the color scheme? That mirrors what we do for the Plasma theme.

The way things are set up currently, not without obscene code duplication. I've been looking into alternative methods for how to get the colour definitions into the theme besides what we have now (that would allow doing this without much code duplication), but I can't get any answers about things necessary for alternative methods.

Conceptually it seems like there are two ways to go:

• Have a single Breeze theme that always follows the color scheme
• Expose the ability to force the use of a particular color scheme via some UI (for example adding "Breeze Dark" and "Breeze Light" themes that always use the colors of the color schemes of the same names).

But I think it will be terribly confusing if we add themes that *only* hardcode the colors of certain elements like checkboxes and windeco buttons. It should be all or nothing IMO.

One alternative UI for this that I've been tinkering with in my mind is as follows:
We have only a single "Breeze" GTK theme which follows the color scheme by default. Then there's a "Configure" button that lets you tell the theme which color scheme to use, with the list populated with all the installed color schemes, and defaulting to "Use system color scheme".

In D24122#561773, @ngraham wrote:

Conceptually it seems like there are two ways to go:

• Have a single Breeze theme that always follows the color scheme
• Expose the ability to force the use of a particular color scheme via some UI (for example adding "Breeze Dark" and "Breeze Light" themes that always use the colors of the color schemes of the same names).
  
  But I think it will be terribly confusing if we add themes that *only* hardcode the colors of certain elements like checkboxes and windeco buttons. It should be all or nothing IMO.
  
  One alternative UI for this that I've been tinkering with in my mind is as follows: We have only a single "Breeze" GTK theme which follows the color scheme by default. Then there's a "Configure" button that lets you tell the theme which color scheme to use, with the list populated with all the installed color schemes, and defaulting to "Use system color scheme".

I'm talking about a more technical difference that would allow said themes with 100% hardcoding to exist without duplicating the entire set of stylesheets for each theme.

Basically, GTK will always read the user's gtk.css and will always load the colour definitions, always overriding whatever is in the theme.

I'm looking for options that will allow themes to not get their colours overridden, but as I said...

I can't get any answers about things necessary for alternative methods

I see.