QWidget mouse events - different order

[Rick Stockton]

On 12/18/2013 07:16 AM, Martin Koller wrote:
> I've discovered that with Qt5 I get a different order of mouse events on
> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
> double clicking a widget results in Qt4 in:
> mousePressEvent 
> mouseReleaseEvent 
> mouseDoubleClickEvent 
> mousePressEvent 
> mouseReleaseEvent
> but in Qt5 in:
> mousePressEvent 
> mouseReleaseEvent 
> mousePressEvent 
> mouseDoubleClickEvent 
> mouseReleaseEvent 
>
> I tested with Qt4.8.5 and Qt5.2.
> Is this behavioral change intended, undefined, a bug ?
> (it results in my app not behaving as before ...)
Martin, IIRC, this was an intended change within the platform-specific
code, and results from changes which I wrote during pre-5.0 / pre-5.1
time frames. (Varied by patform - l5.0 for XCB and defunct Xlib, 5.1 for
OSX,and Wayland,  and so on.)

Explanation of current behavior:
We receive the second click and "push" it immediately (the physical
action), and then determine that the very short time delay constituted a
LOGICAL double-click at the same instant, and we push that event
second. This order allows programs to use the evt preceding the final
Release ("Press " versus "DoubleClick") as the UI "action" to perform. I
understand QT's traditional implementations (in user programs) to take
actions following the "Release" event, rather than than the "Press".

IMO, the new behavior is "more" logical, and allows programming to use
the type-of-press IMMEDIATELY preceding Press/DoubleClick type.  But it
is definitely not compatible with Qt4, and (as you see) forces some
programs which implement code for mouseDoubleClickEvent to create
alternate event handler code for the Qt 3/4 versus Qt5 (and future).
- - - - -
The order of events in Qt5.x QML and Widget Apps must be identical, of
course. So, if we need QML to behave exactly is it currently does, then
Widgets should stay as they are (in Qt5), and this becomes a
documentation bug. Programs which depend on touch "Mouse emulation"
behaviors might also be effected by new code attempting to switching back.

KDE Readers: Has anyone noticed this change, and do you need it to be
have as before?

Should I Leave it as it now behaves (create documentation of the
change), or set it back to Qt4 behavior (which I personally don't like)?

-- 
GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A