Pull from master

In D24275#571531, @GB_2 wrote:

Works now :-)

In D24275#546111, @GB_2 wrote:

In D24275#538994, @cblack wrote:

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

Nope, still shows the error.

You would probably want to use icon instead of menu, as menu is only rendered as a fallback for a pattern that most GNOME applications don't use nowadays.

I was doing some usability testing on the current settings organisation, and here are the results:

• "Plasma" is being interpreted as a material rather than a brand name
• Login screen settings are not in a place people will think to look for them
• Emoticon configuration is associated as being with fonts, not with icons
• Title buttons are associated with window management, not application style
• Date & Time's location resulted in the only "no idea" reply
• Launch feedback is associated with icons or window management rather than applications
• Network shares went completely under the radar - they're under a generic tab labelled "Settings"
• People associate KRunner with the shortcut, not the search

In D24660#567598, @zzag wrote:

• Snapping can be a bit odd as CSD windows can sometimes not realize that their size has changed until after you let go of the mouse

Is this something that needs to be fixed in the compositor itself? How can I reproduce the issue you've described?

I've been using this patch for a while, and here are some things I've noticed:

• Thumbnails include window shadow; this appears fine in alt-tab switcher but on panel switcher thumbnails they're drawn with a solid background.
• Snapping can be a bit odd as CSD windows can sometimes not realize that their size has changed until after you let go of the mouse
• The shadows don't really fare well when you turn off compositing; toggling compositing while application is running does not seem to be an expected use case in GTK.

In T10611#208756, @zzag wrote:

Window decorations (fixes https://bugs.kde.org/show_bug.cgi?id=414113)

Not all decoration themes draw circles around decoration buttons, so that's probably CANTFIX. On the other hand, we could synchronize kwin's decoration button layout with the gtk-decoration-layout property.

In D25336#563292, @ngraham wrote:

Thanks! Can you add a link to the bugfix in the description section so it's easy to reference? And has the upstream bugfix made it into a release yet such that we can count on it being present for users with rolling release distros, or users whose discrete-release distros eventually settle on Plasma 5.18?

I'm not a fan of dropping the diagonal movement- the transformation makes buttons feel much more button-y.

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

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.

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?

See D25281.

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?

In D25015#560515, @ndavis wrote:

One thing we might need to do in order to finally stop changing the shadows is come up with a math based system for deciding how shadows should look based on the elevation we want certain UI elements to have. We could copy Material Design shadows, but I don't think we should. MD's shadows get darker the larger they are, but that's not how real shadows work. Real shadows get darker the smaller they are because light bounces around.

In T11979#207057, @ognarb wrote:

This welcome dialogue are very popular, for openSUSE this looks like this:

. Note this is a distribution welcome dialogue and not a first run dialogue like in KDE 2 with configuration. So I wouldn't include configuration links.

This LGTM. Would probably check a variety of configs with a variety of applications just to be on the safe side and make sure there's no visual oddities, but it should be fine.

In D24126#556711, @wbauer wrote:

In D24126#556709, @ngraham wrote:

Doubtful; it relies on the scss rewrite which happened in 5.15 or 5.16 IIRC.

Indeed, 5.12 didn't use scss yet to generate gtk.css, but contains the gtk.css in the first place.

It should be possible to adjust that directly though, no?

Reverse checkboxes in menus as well

In D24786#550396, @ndavis wrote:

I think it might be a bit premature to copy the look of Plasma Mobile at this point. I don't know what is likely to change and what is likely to stay. I expect that it will mirror the look of desktop Plasma, which will mirror the look of the Breeze widget style.

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?