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

[Olivier B.]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210528/d959ca38/attachment.html>