qt: qml: implement rubber band selection
Qt Quick is oriented towards touch screen, and it does not provide some features that are essential for desktop applications. One of these feature is rubber band selection, which allows multiple selection by dragging views.
This merge request implements a generic rubber band selection. It works by asynchronously checking child items if they are overlapped on the rectangle selection indicator.
It has O(n) complexity because of running through all items. This can be optimized for specific usages, such as list view 1. But this generic approach allows it to be used in other places, such as custom views. I propose it as is, with room for potential improvements.
Note: Obviously, it does not work on touch screen.
Fixes #25568.
simplescreenrecorder-2021-11-22_20.20.42
Merge request reports
Activity
added MRStatus::Reviewable label
added Component::Interface: Qt label
changed milestone to %4.0
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
added MRStatus::InReview label and removed MRStatus::Reviewable label
some feedback on the usability, probably for a future MR.
- we should probably allow to move the view while selecting when the mouse is at the top/bottom of the view:
- selecting in ListView is a bit hard as clicking on the item will trigger the DnD, file browser usually tackle this by making only the name & thumbnail activating the drag&drop or by making the item not DnD in the view margin
Auto scroll should be factored. There exists two auto scrolling based on dragging (in toolbar editor, and in the playlist). Also, they use SmoothedAnimation and it alters the animation based on content size. I thought using
velocity
instead ofduration
would correct this behavior, but turns out it just changes the average velocity. I will create a new issue for this, now.For the other issue, what comes to my mind is that childAt() can be used to determine the first visible item of the parent (delegate), and if it is the background, don't accept the event so it propagates. I can try to do that if this gets accepted.
I will create a new issue for this, now.
OK
For the other issue, what comes to my mind is that childAt() can be used to determine the first visible item of the parent (delegate), and if it is the background, don't accept the event so it propagates. I can try to do that if this gets accepted.
isn't that already what happens? my understanding is that when you click, your mouse event is first intercepted by the child, which starts a drag, otherwise it goes to the parent (so the background) and here it goes to your rubber hander
Yes that is what happens from the context of the view. But when I think about the delegates specifically, because it has a MouseArea that is filled itself, it handles mouse events itself.
The question is, should the delegate accept mouse events, if the mouse is over its background (not the view's background)?
Maybe childAt() to check if the result is control.background can be used, to determine whether the mouse event would be accepted or not.
added 7 commits
- 61a7a7e2 - qt: add ItemOverlapNotifier
- a22ff5a1 - qt: qml register type ItemOverlapNotifier
- d4d6c5f2 - qml: add rubberband rectangle selector style properties
- 89b7550c - qml: add RubberBandOverlapNotifier
- bb8b3d11 - qml: add RubberBandSelector
- 41121117 - qml: use RubberBandSelector
- 7c449c35 - qml: connect context menu signals in medialib views
Toggle commit list- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
- Resolved by Fatih Uzunoğlu
added MRStatus::NotCompliant label and removed MRStatus::InReview label
mentioned in issue #26377