Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
6.5.1
-
None
Description
Run the attached file ListView_Scroll_test.qml in qmlscene and hover over the list item labeled "6" and the view will scroll to fully display the highlight effect.
Normally this is fine, but certain UIs may not benefit from the automatic scroll behavior for various reasons. KDE bug report https://bugs.kde.org/show_bug.cgi?id=387797 shows many complaints stemming from this behavior in our lists, especially those with tall list items, or list items where the cursor must move vertically over the bottom item to reach the top one. If the bottom list item is partially out of view, then passing over it will cause it to scroll fully into view, which can cause the top list item to scroll partially or fully out of view. This has caused some user frustration for users of our System Tray popups, particularly the Clipboard which has variable-height list items.
We have tried setting `highlightFollowsCurrentItem: false` and manually setting the highlight's `y` value on hover (See the attached ListView_Scroll_test_no_highlightFollowsCurrentItem.qml) file, but the problematic behavior remains. It seems like if there is a Highlight effect, it always scrolls the view to ensure that it is visible.
What does work is setting `highlightFollowsCurrentItem: false` and integrating the highlight effect into the delegate itself (see attached fileĀ
ListView_Scroll_test_inline_highlight_effect.qml) but is isn't ideal to have to make a highlight effect in this way, and amounts to a workaround.
This is not a recent regression; it's been a minor issue for KDE for years.