[Qt-interest] Please help me understand mouse/touchpad events and "mouse-ahead"/"touch-ahead"

[Constantin Makshin]

I can't say for sure what exactly the word "invariants" means in that sentence, but I guess it may warn about possible breakage of things like objects hierarchy caused by removing QEvent::Child* types of events caused by careless call to one of QCoreApplication::removePostedEvents() functions.

Removing touch (QEvent::Touch* types) and/or mouse press/release (QEvent::MouseButton* types) events should be safe though, I think. Something like this:

QCoreApplication::removePostedEvents(NULL, QEvent::TouchBegin); // 1
QCoreApplication::removePostedEvents(NULL, QEvent::TouchUpdate); // 2
QCoreApplication::removePostedEvents(NULL, QEvent::TouchEnd); // 3
QCoreApplication::removePostedEvents(NULL, QEvent::MouseButtonPress);
QCoreApplication::removePostedEvents(NULL, QEvent::MouseButtonRelease);
QCoreApplication::removePostedEvents(NULL, QEvent::MouseButtonDblClick);

(2) without (1) and (3) may be a not very good idea because (1) indicates the beginning of a sequence of touch events, (3) indicates the end of this sequence and having "there'll be some events" and "there were some events" without anything in between... :)

Removing mouse press/release events may be useful because "On some windowing systems, mouse events are also sent for the primary touch point. This means it is possible for your widget to receive both QTouchEvent and QMouseEvent for the same user interaction point".

On Wednesday 21 July 2010 18:18:01 Atlant Schmidt wrote:
> Folks:
> 
>   I'm trying to understand how Qt deals with the problem of changing screens
>   versus pending "mouse-ahead"/"touch-ahead" events.
> 
>   Here's my basic scenario:
> 
> 
>  *   I'm developing for a relatively slow target system. Many of
> the screen changes that we do take a significant fraction
> of a second to complete.
> 
> 
>  *   We use a touchscreen for most user input.
> 
> 
>  *   Our touchscreen driver and Qt seem to collaborate to create
> "touch-ahead"; that is, there seems to be a queue of user touch
> events that Qt then processes when it can.(1)
> 
> 
>   This creates a problem for us. Suppose we have a button drawn on the screen;
>   let's call it "Do serious action". The user presses it and we begin processing,
>   eventually putting up a screen that will display a button that says "Confirm
>   serious action". But meanwhile, the user presses down a second time on the
>   screen area that still contains (or just very recently contained) the "Do serious
>   action" button. Maybe it was a touchscreen bounce or maybe our slowly-changing
>   screen led them to doubt that they actually pressed "Do serious action" so they
>   pressed it again; in either case, another touchdown event for that screen region
>   is enqueued.
> 
>   You can see where I'm going with this: because of the "touch-ahead" touchdown
>   that has been enqueued, the user might end up confirming the serious action
>   without really intending to do so.(2)
> 
>   Surely this problem has been solved in Qt, right?
> 
>   But I don't see how.
> 
>   The only mechanism I see is the QCoreApplication::RemovePostedEvents()(3)
>   method. Using this, we could simply remove all pending touchpad events each
>   time we finish refreshing the screen, assuring that we won't receive any user
>   "touch-ahead" that was generated during the display of the previous screen.
> 
>   But that method comes with the advice that:
> 
>     "You should never need to call this function. If you do call it,
>     be aware that killing events may cause receiver to break one
>     or more invariants."
> 
> 
>   My problem isn't very unique so if I "never need to call this function", then
>   it's likely that Qt has solved my problem in a different way and I'm just not
>   seeing it. ;-)
> 
>   Also, I don't understand what the second part of that advice is telling me
>   (about breaking invariants). What state does it break to remove pending
>   events from a queue?
> 
>   Does anyone have any advice for me? Is there a smarter way to handle
>   this problem, for example, is there a global way to disable "touch-ahead"?
>   Or do most people never see this problem because their systems simply
>   run fast enough to mostly-hide the existence of the problem?(4)
> 
>                                     Atlant
> 
> 
> 
> (1) This item is an assumption on my part but seems to be borne out by
>      testing.
> 
> (2) Yes, I understand we could put the "confirm" button in a different part of
>      the screen than the "Do serious action" button; this is just an example
>      and my question really applies to the general case.
> 
> (3) http://doc.qt.nokia.com/4.6.3/qcoreapplication.html
> 
> (4) I'd really like a faster target system, truly I would, but it's not going
>      to happen.