Looking at documentation, the colour module should gracefully fail when it's unable to locate the colors.css, however I have not tested this.

Fix memory leak

Drop meson.build, clean CMakeLists.txt, rebase on master

@ndavis ping

@ndavis do you want to take over this revision? You have a better sense of what this icon should be than I do.

Swap in gridUnit instead of largeSpacing

Remove extraneous print

Add license headers to two new QML files

Move source selector to bottom of column, hide by default

Address feedback

Cache data from the MPRIS sources

Use toolbutton (for initial visual feedback; need to apply colour scheme as to prevent legibility issues)

Fix plasmashell freeze

Address feedback

Adjust layout of components

Be sure to add a copyright/license header to the new QML file you added.

Use a rich grey instead of a rich mahogany

Adjust colour from blue to mahogany

In D26716#597173, @zzag wrote:

In D26716#596682, @cblack wrote:

I can't tell if this is GTK or KWin's fault, but surface resizing with CSDs is a bit wonky with this patch.

At least it exists, which is better than where it was before.

Huh, I am aware of a similar issue but it is related to the minimum and the maximum specified window size (which I'm working on). Just to be sure, can you build KWin without this patch and check whether you're still able to reproduce these resizing issues? In order to resize a window, press Alt + RMB and move the mouse around.

I can't tell if this is GTK or KWin's fault, but surface resizing with CSDs is a bit wonky with this patch.

If you're going to do this faux sidebar thing, why not just split the accessibility KCM into multiple KCMs so it can use the proper system settings sidebar?

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