would be nice if clicking anywhere in the row activated that row's checkbox

These listitems shouldn't change their background colors on hover, since nothing happens when they're selected. You can see how I did that in https://cgit.kde.org/plasma-desktop.git/commit/?id=5a5e0bc0880b6b21c60b5f874f7eddc2a7939a48

Perhaps this should be checked when creating a new rule, or else it looks like there aren't any properties you can apply to the window when creating the rule

Add a centered placeholder message using a disabled level 3 Heading in here when there are no rules

Disable this when there are no rules

All button text needs to begin with an action verb and end with an ellipsis if more actions are required to complete the action. So this should be "Add New..."

Give this a minimum width, or else the rowlayout gets wider with every digit added to the number and resizes the combobox next to it

Maybe "Exact Match" should be the default settting so this message isn't always shown for every new rule you add

I have tried it, but it was a bit messy since the editor page does not differentiate when it's a new rule or any other. If I set it whenever no optional settings are enabled, it gives a confusing feeling with all the rows just appearing and dissapearing on a single check.

Maye a hint like this suffice?

Agree. I have set it in a simple way for new rules added.

I would like though, to set this directly on the config schema defaults, but for that to work I'll need to modify some bits of the KConfigXT helper classes, which I have planned for a later patch along some other changes to improve integration.

Hmm, this is not fixed yet for me. Probably you need to put a MouseArea inside the ItemDelegate that toggles the checkbox if clicked.

Same here; would be nice if clicking on the icon or text also activated the checkbox.

Give it ellipses ("Import...")

Needs to be a bit bigger; the text still expands when set to 100%.

oh, silly me! I did that on the main list selection when exporting.. will repeat it here

Ok. I might have a slightly smaller font.
Is there a not very hackish way the get the width for "100%" with user's font?

Allow me to introduce you to TextMetrics! It can be used for exactly this. Elisa uses it all over the place for just this purpose.

I'm not so sure here. Since this is a complex item, I find toggling selection on text click unexpected, and any misclick can be confusing. Deselecting will hide the item (it's like removing it from the list), and only activating on click would be very inconsistent.
So I'd rather keep the selection action here to the checkbox.

let's use edit-delete for this, as that uses a trashcan icon and we're moving towards using that everywhere

the list items are back to changing their background on hover, which isn't necessary

Might be a good idea to move the "Add properties... button right below this text so it's obvious to the user now they add more properties. When the placeholder message is not shown, the button could just be there at the bottom of the list, and maybe could change its text to "Add more properties..."

The reason for this is to make it easy for the user to understand what they need to do. We do this in the online accounts KCM:

I would make this footer a header to mimic the natural flow. Typically you'll click the "detectwindow properties" button first to target a window, which means it should be at the top of the window to suggest that it's the first thing you want to click on.

Button titles use Title Case ("Detect Window Properties")

use Title Case and add ellipses ("Add Properties...")

Use %1 instead of the hardcoded number 1 for the singular case (there are languages where e.g. the number 21 uses the singular form)

Is this necessary to manually assign? I thought LayoutMirroring.enabled got set automatically?

Can you add a TODO or FIXME comment indicating that this works around https://bugs.kde.org/show_bug.cgi?id=403153?

Add braces, either on the same line, or in the more conventional multi-line style

elision only works when a label's maximum width is defined; you probably want to set that somehow, or make it not elide

That's correct; it's not required unless the spinbox is editable.

In English at least, this minimum width isn't high enough to avoid the spinbox getting wider when going from 1 to 2.

Same deal for the singular case here; use %1 instead of 1

always manually set width to the list view's width on delegates (e.g. width: overlayModel.width)

due to a Qt bug, left and right margins are not reversed in RTL mode. So whenever you set one of those, yo need to explicitly handle the RTL case like this:

Layout.leftMargin: !LayoutMirroring.enabled? Kirigami.Units.smallSpacing : 0
Layout.rightMargin: LayoutMirroring.enabled? Kirigami.Units.smallSpacing : 0

(same for all other instances of using left and right margins on an item in a layout)

Needs to be vertically centered, or else this happens:

(probably do the same for other items in this rowlayout as right now their being vertically centered is by chance rather than done explicitly)

Is there a reason to use opacity rather than visible here?

This doesn't do what you think it does.

searchField.focus doesn't mean, "focus the search field", it means "allow the search field to *become* focused. The property is terribly mis-named. :(

You probably want to set focus: true on the search field itself, and do searchField.forceActiveFocus() here.

Then again I would imagine that the search field internally has focus: true set so setting it again here may be unnecessary.

Could we handle the tab key here too?

We shouldn't be working round Qt bugs.

Also..if you do that, what will happen when Qt does fix it?

searchField.focus doesn't mean, "focus the search field", it means "allow the search field to *become* focused. The property is terribly mis-named. :(

That's not right.

focus does mean "become focussed".

However, it means "become focussed within the parent focus scope".

Focus Scopes are a super simple concept that are simultaneously very very very confusing, to the point that I can't explain them well.

In this case ListView is our focus scope, so we also need to make the listview focussed in order for it to have any effect.

forceActiveFocus() iterates through the tree doing that.

You're right, it works automatically now!
It didn't previously for me, so maybe something was fixed for Qt5.14

I reworked all the Layout hints to use preferredWidth instead of max/mins and it seems to work much better, including the elidedlabel.

Having hoverEnabled: false does not allow to show the delete button on hover only.
The other option is to have it always visible, which is not as a bad as I though, and is indeed cleaner than having the background changing colors

As a kind of middle way, I set the two margins to the same value

It is to preserve the space of the button in the Layout when hidden

I'm not too proud of this, but it was required to avoid this overlapping

good solution :)

FYI: https://codereview.qt-project.org/c/qt/qtdeclarative/+/297558

I'll look into it. Thanks!