Also, should this maybe go into 5.18?

In D27114#604975, @davidedmundson wrote:

Only one comment:

abstract_client.cpp:1333 hasn't been updated

• Add some missing fromMSecSinceEpoch
• Use currentDateTimeUtc in tests

Arguably it might even be better to completely remove the QDateTime usage here and switch to something like std::chrono::time_point or so, but that is a much more invasive change.

Note that I did spend some time investigating what causes the clipping to be needed in the first place, but that looks like an issue deep in kcmshell5, which allows any kcm to be resized to below its minimum size. This also leads to issues with other KCMs like https://bugs.kde.org/show_bug.cgi?id=398797

That's because the KCM for some reason does not want to size smaller even when the kcmshell window does get smaller. This is not related to the scrollbar however, I get the same result without the scrollbar:

• Use QQmlParserStatus to slightly delay syncing of role names

Something I noticed just now while trying to use this: the filterString property has disappeared. PlasmaCore.SortFilterProxy does have this. I think we should restore it, otherwise you need to manually call QSFPM::setFilterFixedString or hope that you can set it as a regular expression.

Or is QML's rotation property not the right property to use?

KScreen uses QML, so it may well be that the buttons were rotated using QML's rotation property, which does rotate the frame, since that's rendered by qqc2-desktop-style's StyleItem as a sub-part of the button.

The logic for placing the scrollbar is in ScrollView already. Since the delegate no longer needs special padding, this changes the padding to the same value for left or right. We could change the padding depending on where the scrollbar is, but I don't think that would be an improvement.

In QQC there is an issue of overlap between item selection (and header titles) and scrollbar. Isn't that made even worth with the addition of the thin separator ?

There should be no need to explicitly specify paddings now that D26530 has landed. But there's a bunch of workarounds that we still need to remove, so you may have some intermittent weird results.

• Review comments

Also, just want to reiterate that I actually don't really care about how things look, what I care about is the amount of workarounds that are introduced by the scrollbar behaviour as it is. One current example is D26586 but I have ran into this myself when doing application development, as well as seen other people run into it. The workarounds introduced easily break, either with a different QtQuick Controls style or even with just a different widget style. Take a look at the System Settings sidebar with Oxygen for example. They also repeat code and lead to bugs due to that, like missing handling of LayoutMirroring.

yes, i'm saying that the patch besides putting the separation in the frame, it also reintroduces the frame by default, which is unrelated (and i think it should be avoided)

Note that the interaction model is that way because that's how the system locale works. The KCM sets a bunch of environment variables (LC_ALL and related) which Qt then uses to determine what format to use. These generally correspond to certain country formats. While in theory it might be possible to create custom locales, I have no idea how hard that is to do.

Getting back to the topic of naming: I just did a real quick search for "zephyr" or "zephyr style" and could not really find anything obviously style related. Therefore I would suggest to use Zephyr as the new style name.

Also note that the intention is to have the scrollbar background match the view background. In the example case I didn't bother with any view specific styling, so it looks a little more ugly than necessary. This is what it would look like with fixed background styling:

I think overlay scrollbars just cause more problems than they solve. Basically every application developer needs to account for the scrollbars, rather than just using ScrollView without bothering about it. Additionally, as mentioned, it is inconsistent with all the other views we use.

@mvourlakos Is there currently a D-Bus method for starting Latte that can be used? Asking to save myself looking around for it when I work on the Global Theme KCM Code once more.

The bug mentioned got fixed by this (old Qt doesn't iterate over QList).

I don't see how this would make it look any different. The kirigami visible patch is indeed necessary but for an entirely different reason.

Silly sip :/

Already I can see one hurdle: Non-running Latte Dock. How would we go about doing the import command best: Would we go about running latte-dock's command through the C++ system thing (usually regarded as being insecure) so it works if Latte Dock isn't running? Is there another, more secure, C++ equivalent to its "system" code to launch Latte Dock?

I've created https://phabricator.kde.org/D26279 for the overflow menu.

• Remove unrelated flat change

• Don't show busyindicator when there are no jobs

• Use visible to hide the busyindicator when progress > 0

• Explicitly set opacity

• Re-add hiding behaviour on mouse over

• Remove limiting to just showing the last 10 seconds
• Replace ToolButton IconItem with custom to fix alignment

• Add missing @since

• Actually set qml profiling to ON by default