(fix) Drag'n'drop: avoid unintended drag on hover (WTrackProperty, WCoverArt etc.)

[ronso0]

Fixes #13033 on Linux with Qt 6.2.3

[ronso0]

@m0dB Do you have any idea what's going on?
Can someone reproduce with a Qt version other than 6.2.3?

[ronso0]

Meeh, breaks dnd in the tracks table... wtf

[daschuer]

I think it is an issue that in mouseMoveInitiatesDragHelper()

    static qreal pressX{};
    static qreal pressY{};

are static and are never reset.
Any mouse move initializes the drag event than.

[daschuer]

I am able to reproduce it without a hover effect.

[ronso0]

Okay, thanks.

However it's different with WTracktableView:
no unintented drag in the first place, but:
on drag, the event catched by mouseMoveEvent doesn't have a button flag (Qt::NoButton).

[daschuer]

Before #12903, the check for the pressed button was in the mouseMoveEvent() of each widget. Maybe we want to reintroduce it.

[ronso0]

I think it is an issue that in mouseMoveInitiatesDragHelper()

    static qreal pressX{};
    static qreal pressY{};

are static and are never reset. Any mouse move initializes the drag event than.

Appearantly. I managed to suppress unintented drag by initializing them both with -1.
We could reset on click release.

Turns out I don't fully understand the combination of static function + namespace inline function with static var.

[daschuer]

These static vars are like globals, hidden in a function scope.

[ronso0]

However it's different with WTracktableView: no unintented drag in the first place, but: on drag, the event catched by mouseMoveEvent doesn't have a button flag (Qt::NoButton).

Uff, there's a difference between
QMouseEvent::button() == Qt::LeftButton return false
QMouseEvent::buttons() == Qt::LeftButton return true
QMouseEvent::button().testFlag(Qt::LeftButton) return true

edit at least for mouse moves.

[ronso0]

Works as expected with all track widgets and the table.

[ronso0]

I think it is an issue that in mouseMoveInitiatesDragHelper()

    static qreal pressX{};
    static qreal pressY{};

are static and are never reset. Any mouse move initializes the drag event than.

Turns out that doesn't matter with the correct button filter.

[ronso0]

@mixxxdj/developers Could someone take a look please?
After merging #11755 (with WTrackProperty:hover) main is broken for me (#13033).

Drag'n'drop should work as expected and no unintended drag must occur.
Test hover/drag with
WTrackProperty
WTrackWidgetGroup (track color lines in LateNight)
tracks table
cover art (decks and library)

[m0dB]

I'll take a look when I have a moment, hopefully tonight (CET).

[m0dB]

LGTM, merged. Thanks for taking care of this while I was away.