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. :-) _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
