<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - fail to receive touch_frame after final touch_up (Qt)" href="https://bugs.freedesktop.org/show_bug.cgi?id=83383#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - fail to receive touch_frame after final touch_up (Qt)" href="https://bugs.freedesktop.org/show_bug.cgi?id=83383">bug 83383</a> from <a class="email" href="mailto:shawn.t.rutledge@gmail.com" title="Shawn Rutledge <shawn.t.rutledge@gmail.com>"> Shawn Rutledge</a> <pre>I should rather say that the Qt touch handling strategy is to accumulate touchpoints and then handle them when we receive a touch_frame, and that in turn is because of the architecture that multiple touch points are grouped into a single QTouchEvent. We've been thinking of having separate events for each touch point movement in Qt 6 (can't do such big changes in Qt 5). This would help to facilitate a better event inheritance tree so that handling of mouse, touch and tablet events could be unified in some elements that don't care much about the differences between them (if there is to be a QPointingEvent base class from which QTouchEvent inherits, it should have only a single pair of coordinates). And multiple mice could be treated much like multiple fingers (except that multiple mice tends to imply multiple users, so maybe we need a "seat" concept like wayland has). If we did that, then maybe it would be appropriate to ignore the touch_frame entirely, which might improve reliability. But for now we depend on it, because we generally don't send a QTouchEvent until all the touch points have been updated (except for this latest workaround when all touch points are released).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>