[Development] QWidget mouse events - different order

[Rick Stockton]

On 12/30/2013 12:50 AM, Rutledge Shawn wrote:
> On 23 Dec 2013, at 5:37 PM, Rick Stockton wrote:
>
>> QTBUG-25831 is re-opened, and assigned to me. The linked gerrit change
>> would "solve" the problem for Widgets- creating the issue
<snip, issues>
>> Shawn Rutledge has suggested making the change configurable (see his
>> comment in the bug, he says it much better than I can paraphrase).
> I don't think I did any work on this (unless I forgot something), other than thinking a bit and making a comment.  ;-)  But I'm glad that a plan seems to be coming together.
It was a great suggestion ;-) However, Laszlo has inspired me offer
something quite different. This is BC with the entire 5.x series, and
doesn't add any new API.

(BTW, this post duplicates a comment in the bug. I think it's of general
interest to the ML).

We might define one of the unused high order bits within
Qt::MouseButtons as a flag, indicating that the event (always an event
of type 'MouseButtonPress') is a "FastMousePress", which means that a
corresponding  "MouseButtonDblClick" has also been created. (Background:
I'm the person who extended Qt::MouseButtons from 16 bits to 32 bits -
and I think that we'll never need to extend Mousebutton flags to handle
more than 27 buttons. So the only "problem" is one of nomenclature,
using a bit within Qt::MouseButtons for something *different* than a
Button Pressed/Unpressed State flag.)

Qt programmers who don't explicitly work with MouseButtonDblClick events
would continue to get the MouseButtonPress with zero code changes. At
the same time, those programs which DO handle Double Click events could
avoid adding nasty nasty timer and button comparisons in their event
filters. Instead, they just check the flag if they want to ignore the
"duplicate" ButtonPress event (or accept it, while doing nothing). For
example, following event filter snippet:

if (event->type() == QEvent::MouseButtonPress) {
   if ((event-> buttons() && Qt::FastMousePress) {
      event->accept(); // "eat" the event, but do nothing with it.
} else {
   // handle the ButtonPress (it is unique, and doesn't have a
DoubleClick "duplicate")
}
if (event->type() == QEvent::MouseButtondDblClick) {
  // handle the DoubleClick events
} 
 
Over time, at our convenience, we can add this conditional "accept and
do nothing" code into Widgets (and etc.) which DO take action,
internally, upon receiving a MouseDblClick event. But it wouldn't break
anything. Our code blocks which test the State of individual buttons, in
a loop, end the loop when the shift reaches Qt::MaxMouseButton. Note
also, that a few existing LOC with statements like this:

if (!buttons) ..... // do stuff for the case of no buttons pressed

... are not going to be need any changes, because every MouseButtonPress
event has at least one of the "genuine" button flag set anyway. Setting
a high-order bit won't change the behavior.

This capability/enhancement can be done by adding just a few lines in
qnamespace.h, with doco, and some usage documentation within
QMouseEvent's doco. Unlike my first approach, it's low risk (IMO). Does
anyone have an objection to this approach?