[Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options
volker.hilsheimer at qt.io
Tue Jun 1 21:41:04 CEST 2021
The good news: changing the default breaks surprisingly few tests.
The bad news: it’s not because the whole thing is particularly well tested
So, I now added a bunch of tests for the whole thing that also highlight the two cases that are UX-bugs via QEXPECT_FAIL:
The follow-up commit has the fix for ExtendedSelection, where we can stay mostly with the current behavior, except for Ctrl+Press.
MultiSelection is a bit more challenging (and sadly also the bigger usability issue); the drag-selection logic has not quite revealed itself to me. If anyone wants to attempt a patch on top, be my guest - that the new (as well as the selectionCommand) test need to be adjusted is expected.
> On 1 Jun 2021, at 15:25, Lars Knoll <lars.knoll at qt.io> wrote:
> Of course. The +1 only applies to Qt 6, and not any versions of Qt 5 :)
>> On 1 Jun 2021, at 14:58, David Skoland <david.skoland at qt.io> wrote:
>> To be clear: +1 to changing default behavior in 6.2.
>>> On 1 Jun 2021, at 14:57, David Skoland <david.skoland at qt.io> wrote:
>>> Not thrilled about subtle default behavior changes like this, there’s no knowing how it may break certain apps. I suppose most people will be upgrading from 5 to 6.2 and will to some degree expect having to make some adjustments and the proposed behavior is definitely desirable, so I’m giving this a +1.
>>>> 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.
>>>> 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)?
>>>> Development mailing list
>>>> Development at qt-project.org
>> Development mailing list
>> Development at qt-project.org
More information about the Development