In T12611#219181, @davidedmundson wrote:

RE: Wallpapers specifically

Yes, that 100% should not belong in the theme.
It's also in the desktop layout package and defined in the lnf package. We should have been clearer to deprecate this when that happened.

Anything remaining of plasma theme should be about low level controls and shapes alone (i.e something an app on plasma-mobile might use) and absolutely nothing to do with plasmashell.

Same concern as voiced in T12612#219183. Similarly, let's focus on T12611 instead.

For example the recent scrollbar UI changes required patches to Breeze, qqc2-desktop-style plasma-framework, and Kirigami. Three are frameworks, one's in Plasma. Getting everything synced has been an ongoing issue.

Oh gosh, every time someone touches that KCM to fix a bug, it breaks something else. :/ It's so fragile.

monitors compositing manager selections

Aha, found what changed it:

RE: Wallpapers specifically

Can you expand on what this task would involve doing?

We previously have discussed several times making the plasma breeze theme (plus the low level SVG classes etc) a tier 1 framework so it's quick to build a nice looking UI from scratch on embedded devices which lack native controls.
Putting this into plasma would go against that.

If QQC2-desktop-style is tied to a specific style then QQC2-desktop-style is failing at it's job. It's meant to be agnostic to all styles, so there shouldn't be a reason to be in sync.

Alternatively, we could move the Breeze widget theme into a framework and not have to do this.

Alternatively, we could move the Breeze widget theme into a framework and not have to do this.

Alternatively, we could move the Breeze widget theme into a framework and not have to do this.

In T12594#219148, @cullmann wrote:

I think this is really very nice!
Thanks again Tyson for all the work you put into this!
For the Breeze submission, I can try to handle that for you, if somebody gives me the right pointers ;=)

What's really the need for this?

But the use of white there is on purpose, of course it breaks the dark themes, but maybe there's a color from https://api.kde.org/frameworks/kirigami/html/classorg_1_1kde_1_1kirigami_1_1Theme.html that we can use?

FWIW this broke artikulate since you changed the expected entry for engine: in KNS.ItemsModel

Heh, it's from V5 days, it was Surface and Popup back then.
At KF6 we can re-adjust the class names to match with the proper hierarchy too

Getting rid of the inversion might be easier to read for simple humans (as me :) ):

const bool isAscii = std::all_of(std::begin(s), std::end(s), [](QChar a) { return a.unicode() <= 127; });

In D26868#602150, @dfaure wrote:

There is indeed a QString overload for concatenating QLatin1String, but it will have to be converted char-by-char (from 8 bits to 16 bits), so isn't it faster to concatenate QStringLiterals?

There is indeed a QString overload for concatenating QLatin1String, but it will have to be converted char-by-char (from 8 bits to 16 bits), so isn't it faster to concatenate QStringLiterals?

No, never const QChar&.
QChar is a short int.

Check window rules only once.

• Restore parameters

I think this is really very nice!
Thanks again Tyson for all the work you put into this!
For the Breeze submission, I can try to handle that for you, if somebody gives me the right pointers ;=)