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.hilshei...@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.barthel...@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.hilshei...@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.hilshei...@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 >>> developm...@qt-project.org >>> https://lists.qt-project.org/listinfo/development >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
