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
