Does this ever happen? focus != activeFocus

Doesn't ListView take care of highlight placement and visibility?

Unused id

Just make this the MouseArea, saves you one Item per delegate

This is the default

Layout.preferredWidth? I've seen wonkiness with IconItem and Layouts as it has an implicitWidth/height and that has priority over width/height as far as Layout is concerned

Use RowLayout instead of Row and then Layout.fillWidth?

There's a KeyNavigation attached property where you can tell it which the next tab/backtab/up/down item is

event.accepted twice, inside and outside the if

QtQuick Controls Button from which PlasmaComponents Button inherits automatically handles Accessible automatically

Is that API even supported still? We have Plasmoid.toolTipMainText, Plasmoid.toolTipSubText etc

Yes. ScrollArea is a FocusScope. The ListView never loses focus, the ScrollArea does.

Removed and replaced with highlightMoveDuration.

Dropped.

Changed.

I prefer being explicit, but dropped.

Done.

Done.

I know. KeyNavigation never really works well for me, and has issues when you try to combine it with Keys.* as you usually have to when working with the item views. I prefer just stickig to Keys for consistency. It's more or less the same code anyways.

Thanks, copy and paste accident. Now I can actually remove the onUpPressed/onDownPressed again :-).

Dropped.

Well, it worked ... I kept that part from the old code. I changed it now though.

Actually not done; I need to manage this for other reasons.

You're using the margins from this frame, but you're not even rendering this frame anywhere?
Using the margins from something we're not rendering doesn't make really make sense semantically.

Then later we later use the left/right margins from the highlight which makes even less sense. No-one else does that.

We have a consistency problem with list view delegates over Plasma generally, so I this probably isn't any worse, but it's not right.

There is a PlasmaComponents.ListItem which does a fairly good job of handling some of this vaguely consistently. Though that's currently only used by 4 things.

Not tested, but will this work with RTL?

Note if not, you just need an anchors.left: parent.left and it will

it's better to do

height: parent.height
you already have the centering of the text in the text alignment

We use this same technique in Kicker and FV and other places. It's the only way to get element sizes from a themer and cope with themes that miss certain elements. I have asked for better APIs over the years and got a "no" back from Marco every time. This works, and anything else breaks for the user. Our UIs rely on it.

Worked in my --reverse test.

Oh the Math.max() is because the margin sizes differ for some themes and this avoids ui jumps in cases like that -- another real world fix ...

The main bug I'm complaining about isn't you using the margins, it's about how you're then not putting the items in that frame - which is literally the point of the frame.

It happens to be that viewitem/normal is completely transparent on Breeze, but you can't rely on that being the case for all themes.

Plus you don't get the mousedown->selected effect. Krunner is a good example of that working. (btw, that uses ViewItem and most certainly doesn't "break for the user")

...and if you do think it's better to get rid viewitem/normal viewitem/selected - (which tbh I'd be fine with, the current themeing doesn't match ListView's highligh API as it didn't exist at the time) then we *need* to make sure our component matches.

Not s

Can you please summarize all this into a concrete change request for this patch so it can proceed?

(Sorry for replying to the wrong parent, Phab is for some reason hiding your comment.)

Done.