[Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

Turns out that the patch that fixed QTBUG-77771 introduced that behavior change, and - given that I was the one making that patch - I can say that the change you are observing is an unintentional side effect.

Created https://bugreports.qt.io/browse/QTBUG-94087 and fix in progress.

Cheers,
Volker


> On 28 May 2021, at 16:00, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
> 
> This seems unrelated, since the JIRA ticket predates both 5.11 and 5.15, so while it does sound like a regression that you’re welcome to report, it won’t help me with deciding about this particular issue.
> 
> 
> Cheers,
> Volker
> 
> 
>> On 28 May 2021, at 15:30, Olivier B. <perso.olivier.barthelemy at gmail.com> wrote:
>> 
>> Here, we have had an issue when switching from 5.11.1 to 5.15.2, with multi selection and dragNdrop
>> Now, if we start a drag n drop, but previously clicked on the item a short time ago (less than the double click delay), then the view starts multi selection with the mouse moves instead of starting drag n drop, even if the mouse leaves the widget area.
>> This did not happen in 5.11.1 with same user code, and dragging was enabled on a double-click+move
>> I'm not sure which behaviour is better, but for our use cases, the former was more fitted.
>> 
>> Maybe looking at what changed between 5.11.1 and 5.15.2 (and why) could help your decision?
>> 
>> Le ven. 28 mai 2021 à 14:58, Volker Hilsheimer <volker.hilsheimer at qt.io> a écrit :
>> Cross-posting from the development mailing list in case any of you have a strong opinion about this.
>> 
>> Volker
>> 
>> 
>>> On 28 May 2021, at 13:10, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
>>> 
>>> Hey Widget fans,
>>> 
>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>>> 
>>> The UX resulting from our (strange) choice to trigger selection changes on mouse press rather than mouse release is indeed quite horrible, as explained in the ticket.
>>> 
>>> The options to fix that seem to be:
>>> 
>>> 1) change the default behavior - always change selection on mouse release
>>> 2) change the default behavior if drag (as per dragDropMode)
>>> 3) make the "selection trigger" a property
>>> 
>>> None of those options would IMHO result in a change that qualifies for stable branches. I’ve for now implemented option 3. This introduces new API, so if we agree that this is the way to go then it would ideally be merged before 6.2 feature freeze next Friday.
>>> 
>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
>>> 
>>> However, the possible property values seem oddly specific to this problem, and give that this is a 6.2 only change anyway, perhaps it would be best to simply change the default, which would then also make Qt matching native UIs better (ie Windows Explorer or macOS Finder)?
>>> 
>>> Cheers,
>>> Volker
>>> 
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>> 
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest