Run icons through SVG cleaner

Remove excess icon

Colour changes

In D24447#547774, @gepardo wrote:

Thanks. Can you please merge it? I don't have a developer access to KDE repos.

LGTM 👍

Shift wind emblem to the right, clean scratch work, and rename night icons

In D24537#545187, @ndavis wrote:

That cyan looks odd. It sticks out way too much and AFAIK, it isn't commonly used to represent wind. Gray on more gray is going to be tricky as well though, especially when you've got partly cloudy vs cloudy. What if the wind was a bit more monochromatic? Wind is invisible, so it only really has shapes that are associated with how it moves around objects to represent it. Perhaps we can use darker colors for lighter backgrounds and lighter colors for darker backgrounds then? Here's an idea for an alternate shape type, but you don't have to use it:

They look nice, but I'm not sure how well they fit in with other Breeze icons.
Comparison montages:

So it turns out I ran into an unrelated bug that at first glance appeared to be the linked bug with my setup, but in reality, it's actually unrelated.

Some examples of exporting colours causing graphical artifacts:

In D24471#543487, @broulik wrote:

it seems to have defaulted to always on

Yes, I did that because it makes sense.

(which is pretty rare)

So, you're saying GTK2 themes are likely to follow color schemes but GTK3 are not?

I meant that it was rare for GTK2 themes in 2019 to attempt to follow the colorscheme, not that it was rare for them to not follow the colorscheme.

(including Breeze GTK) primarily use pixmaps

Basically, we cannot have GTK 2 apps follow color schemes anymore, or did that ever really work?

In D24471#543156, @broulik wrote:

I don't understand what this is solving. Did this work before, if so, what broke it, that suddenly requires this patch?

In D24471#543113, @ngraham wrote:

Is this the other half for fixing https://bugs.kde.org/show_bug.cgi?id=412331?

In D24324#541215, @ndavis wrote:

In D24324#541214, @cblack wrote:

In D24324#541212, @ndavis wrote:

I'm not sure how to verify if the assets have been generated correctly. What GTK2 programs did you test with?

Look for a theme in ~/.local/share/themes called Breeze 🎨. The reason why it has a 🎨 is to distinguish it from the system Breeze GTK2 theme. Otherwise,
there'd be two Breeze entries listed in the user's GTK2 theme list in syse5. Yes, it's clunky, but this is a toolkit older than me, so clunkiness is expected.

I would probably add a "if the user has GTK2 theme set to Breeze/Breeze Dark change the GTK2 theme to the recoloured one" but I'm not sure
what direction GTK configuration is heading with that configuration daemon being worked on, so I'd rather not mess with GTK configuration until that's ironed out.

Am I supposed to run this script myself? I did make install and it didn't seem to do anything.

Are you sure the emoji isn't going to be a problem in programs or systems with no emoji fonts?

In D24324#541212, @ndavis wrote:

I'm not sure how to verify if the assets have been generated correctly. What GTK2 programs did you test with?

Does it work if you use an absolute path to the library? Go to $BUILDROOT/color-reload-module/libcolorreload-gtk-module.so and run gedit --gtk-module $PWD/libcolorreload-gtk-module.so

In T10578#202838, @ngraham wrote:

Welp, we can't use that then, sorry.

In T10578#202831, @ngraham wrote:

I see source code for the desktop app here: https://github.com/ChugunovRoman/figma-linux

Is that the only FOSS part and it requires a proprietary server?

An application launcher of some sort (besides KRunner) seems to be missing

Some suggestions:

• Have the clock show day of the week
• Add an applet that triggers KRunner by the system tray (can't remember if Plasma upstream has one)
• Add a "sidebar" panel to the right with a calendar and notifications applet (auto hiding of course)

Substitute border decoration for fill decoration

In D24127#535551, @ngraham shared an image:

In D24127#535555, @ndavis wrote:

@cblack Can you change the focus state to only have a blue outline? This behavior is really confusing, even though it seems consistent with Breeze: -snip-

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

Fix sliders

Swap out colors

In D24126#535497, @ngraham wrote:

Actually now that I look closely I still see the transparent pixel in the corner from a transparent border radius:

Add selectors for applications like gedit that do not have headerbar as direct child of window

In D24123#535491, @ngraham wrote:

Does this fix https://bugs.kde.org/show_bug.cgi?id=412078? I can't reproduce it myself so I can't tell.

Fix alpha values

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?

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.

In D24122#535474, @ngraham wrote:

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

Remove superfluous border radius

Add copyright to files that I touched a lot

Background color of icons grid now uses view background color again

In D23712#533514, @ngraham wrote:

I'm not sure it's working

Fix sorting, remove hardcoded icons