In D26924#601024, @ngraham wrote:

The scrollbar changes are in 5.18; shouldn't this go to the stable branch instead of master-only?

Just reverting last update, I will create separate revision.

Look good for me, but someone else from KDE team needs to approve this.

Thanks for noticing! The currentValue property was introduced with QtQuick.Controls 2.14 (Qt 5.14). Very convenient, unfortunately Plasma 5.18 must support Qt 5.12.

In D26586#600853, @carewolf wrote:

This change break settings for me due to currentValue in ConfigEntries.qml conflicting. It works if I rename the variable to something else

Iterator used

Issue, notification icon is "bold" now:

Problem was in duplicated role names, which confused ListView/delegate.

Few comments from someone who was recently using PlasmaCore.SortFilterModel and had trouble understanding sorting :)

The question is: should I move this component somewhere else? PlasmaComponents3?

Remove leftovers from tests

Apply to notification icon

Separate component

As proposed by @broulik in Bug 416310 it might be a good idea to create IconEffects.qml (or IconEffect.qml?). Ideally, it should have a feature parity with KIconEffect.
Any recommendations?
Where to put this component (org.kde.plasma.core, org.kde.plasma.components 3.0, org.kde.plasma.extras, org.kde.plasma.workspace.components)?
How to correctly document it?
How to read KSharedConfig from QML?

Is the review (by other Plasma members) done? Please let me know when can I push changes :)

In D26586#594236, @nicolasfella wrote:

There's a minor problem (that I've seen in other place as well). When scrolling the content overflows the frame on the top a bit:

In D26586#594211, @ngraham wrote:

Some of the code looks a bit hairy to me, but I don't see anything catastrophic. :)

In D26586#593966, @ahiemstra wrote:

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.

Anything else to change/fix? When is the code freeze, this Friday?

Replaced hack with explicit padding settings

@ngraham You commented in wrong revision, this one is abandoned :)

Fixes for column size, it is calculated dynamically now

In D26586#593549, @ngraham wrote:

The alignment for items with shortcuts is a bit odd:

Yes, I know. Shortcuts can be really long, you can have some crazy combinations like "Meta+Ctrl+Shift+Z" which is very wide. From the other side, it should not be that bad... I will work on this, let's see what can be achieved.

@mart @ngraham I see heated discussion in D26530. What should I do with scrollbars? I can change it to something like this:

Removed feature that allowed to hide whole category.

In D26586#593154, @ngraham wrote:

There are no sections and everything's disabled.

Hmm, there is one small change in the C++ model (category added), maybe you need to restart/logout so that C++ library is reloaded?

In D26586#593114, @mart wrote:

fine for me too.

Final decision: should I remove feature which allows to hide whole category?

Workaround for Kirigami.AbstractListItem

Review fixes:
Key shortcut header width
Background
Few other small changes

The discussion about overlay vs non-overlay scrollbars is unrelated to whether or not to show a frame and background behind a scrollview. :) Just add the background for now I think.

Oh, true, my mistake. It looks much better with background, thanks!

In D26586#592050, @ngraham wrote:

Much better! The scrollview needs a frame around it though. You can do this by adding this to it:

Is it decided (D26530)? Correct me if I'm wrong, in Kirigami scrollbars are overlaying with transparent background, Kirigami just adds some paddings when needed. Anyway, to have scrollbar seprated it is better to just add one margin to the list (and remove "rightPadding" I added to header, section and list item).

This change is based on the idea from D22176.

Example when current way looks bad: D22176. We can live with that and add margins/padding when needed. Or not :)

• Old-fashioned scrollbars are also bad, they look old and sometimes ugly (especially when list has different styles for odd and even rows). All other systems are moving (or moved) away from this.
• Gnome way is not good either, at least from my experience. It is not intuitive, I'm always trying to scroll using this tiny bar, then realize that it shows bigger version on hover.
• Disappearing is also not good, because it confuses user - sometimes they don't know that list has more elements, you need to hover a mouse over each widget to know the status. From the other side it is consistent with mobile, which is now a reference and most user are more accustomed. Maybe lists that have scrollbars (hidden) should have subtle fade-away effect on edges?

Nothing is perfect. That's why I hate creating UIs :)

It looks abandoned, but rewrite of configuration is very needed, users are confused (and there are bug reports due to this).

In D26545#590861, @ngraham wrote:

FWIW it is possible to restore the original size by using the same tiling shortcut again.

Oh, I tested this on multi-screen setup, but it is working indeed if:

• I use shortcut few more times to iterate all screens
• I did not click to hide popup. If it is hidden, it won't restore.

There must be a better way to fix that. Layout.minimum = Layout.maximum has nice side affect that does what I want, but maybe better place is to change some (?) window flags in PlasmaCode.Dialog?

In D26395#590409, @davidedmundson wrote:

What should be in FIXED-IN? AFAIK 5.18 is frozen. Should I commit it into master?

5.18 doesn't exist yet, let alone being frozen

What should be in FIXED-IN? AFAIK 5.18 is frozen. Should I commit it into master?

This is another approach to fix 357443. It is still a workaround, but more reliable and uses better concept.

I don't know why I missed that, I tested D26079 but obviously not enough.

In D25580#578732, @trmdi wrote:

Please make sure it would not bring this bug back: https://phabricator.kde.org/R120:6fcf9a5e03ba573fd0bfe30125f4c739b196a989

D25580 pushed, @nicolasfella, can you rebase?

Review fix

Review fix

In D25603#569113, @davidedmundson wrote:

Alternatively, if we need to reset something when our window gets moved...could we watch for our window getting moved?
It'll be the more technically correct, and keeps this code agnostic.

No idea how feasible that is though. Your call.

Empty line removed