No complaints here.

Use colourscheme name instead of emoji

Remove commented line

Code-wise, all of the stuff touching GTK looks fine except for the overengineered GTK3 theme preview, but that's relatively minor since it should still work as intended.

The QML code could use some help in the style department. Some changes I would do:

1. Make ID separate from other properties
2. Chunk together related properties in a consistent manner

Zephyr is already used by a lot of themes, so I wouldn't use it for sake of googleability.

Are you going to open a sysadmin ticket about this?

Optimise with Scour

Refine colour palette of icons

The foreground's colour contrast against the base of the colour icon should be higher IMO. (I have to squint to make out the emblem, which kinda defeats the purpose of an icon: making a filetype easier to see.)

Get the other two items unhardcoded

Update based off of feedback

In T12400#214574, @ngraham wrote:

BTW The point seems moot for Dolphin since there's already a Flatpak version of it.

In T12400#214568, @ngraham wrote:

No, one point is sandboxing. Another is decoupling apps' release to users from the distro's own packaging release cycle. Another is providing a single packaging format for developers to target. Another is allowing developers to specify and depend on consistent library versions rather than needing to support whatever random version is in 500 distros. And so on. If these apps in question got on Flathub or the Snap store with no sandboxing whatsoever, it would still be a win over traditional distro packaging.

In T12400#214566, @ngraham wrote:

In T12400#214565, @cblack wrote:

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

That would seem to defeat the entire point of these packaging formats. If they can't handle any kind of app, why bother?

In T12400#214555, @ngraham wrote:

Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

I agree with a lot of the points raised about this. Personally, I think the traditional packaging model is going to fade from prominence sooner rather than later, and KDE Neon should take steps to be ready when distros start packing up and using new and unique packaging formats.

Code looks fine to me.

In T10611#213129, @GB_2 wrote:

In T10611#213121, @ndavis wrote:

TBH, I can't tell if that setting actually does anything on Plasma.

If you set a theme like Adwaita (if you're on neon you need to install gnome-themes-extra and set the GTK3 theme to Adwaita) that has a light and dark variant then it uses the dark one (see https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-application-prefer-dark-theme).

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.