[Development] QWidget mouse events - different order

Rick Stockton rickstockton at reno-computerhelp.com
Mon Jan 13 07:02:09 CET 2014


On 12/30/2013 01:49 PM, Andreas Aardal Hanssen wrote:
> Why keep the breakage though. This fix would still require a note in
> porting docs and changes to code. Why fix what was never broken - just
> go back to Qt 4 behavior..
Hi, Andreas. Please note that the Bug Report, QTBUG-25831, is re-opened,
and most of the current decision-making has been occurring there. Feel
free to comment if you see me moving in a bad direction on this. We
considered, for a short time, going back to the Qt3/Qt4 behavior on a
massive scale - but quickly rejected that alternative, for several
reasons. (Which I will try to cover here.)

(Background) MouseButtonDblClick is largely an artificial construct,
providing "extra information" concerning the 2nd MouseButttonPress
(which Qt5 currently delivers to all listening Objects). Even the name
"DoubleClick" seems a bit unfortunate to me, because it's more of a
"DoublePress", a "Second-Press-Came-Really-Fast" hint to the program. In
my thinking the Qt3/Qt4 behaviors (suppressing a genuine
ButtonPressEvent and creating an interpreted "fake event" in it's place,
on the basis of a hard-coded timer, and calling a "Press" a "Click",
even though the button may still be held down) were less correct.

But it was what it was, and it is desirable to ease some of the
migration problems which result - returning to that "more erroneous"
behavior, in situations where it does NOT break new things done "in the
right way". But among these "new things done right", we have large
portions of Qt itself, which would need difficult re-writes in order to
accommodate a "global" switch back to Qt4's non-delivery of the real,
physical MousePressEvent. Those rewrites would be VERY time-consuming,
and create significant risk of newly-introduced errors. We are
absolutely not going to undertake such a project. I also have the
impression (and I may be wrong) that some of the modern Compositors
which Qt did not previously support (e.g., Wayland) do not define a
mechanism to receive a 'mouseDblClick' event, and we *must* provide the
event which they are designed to receive (mouseButtonPress).

Even WRT Widgets, we agree that programs which perform Actions (or other
kinds of "resultant behaviors") in response to the ButtonPress and he
DblClick have usually been written incorrectly: In nearly all cases, the
programs should be executing those "resultant behaviors" after the
subsequent MouseButtonRelease. A well-written program would already
behave the same as it did in Qt4, because we have not added an
additional MouseButtonRelease, and the "MouseDblClick" is still the
immediately preceding "Press" Event type.

HOWEVER, we also agreed that it appears to be "safe", for Qt, 5.3 and
higher, to eliminate delivery of the second MouseButtonPress for Qt
Widget Windows, and (probably) other Objects derived from QtWidget. Per
above, properly written programs will be unaffected by this change- but
numerous badly written ones, including some Examples and Tests within Qt
itself, could be made more compatible with Qt4 behavior by making this
change. Until it is fully tested, we are only theorizing that the
eliminating delivery of the Second MouseButtonPress is "safe" for all
Widgets. It could become necessary to further reduce the scope of the
change, or even abandon it completely.

BTW, my non-professional understanding puts a fairly severe "filter" on
the IRC discussion this by smart people, a few days ago. I apologize if
I have described anything in a misleading, incomplete, or
just-plain-wrong way, and I sincerely INVITE corrections for this post. :-)




More information about the Development mailing list