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

[Atlant Schmidt]

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.



________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100721/96db0908/attachment.html