Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-90296

Enable device-agnostic pointer event handling in Qt Quick

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • P3: Somewhat important
    • None
    • 6.0.0
    • None

    Description

      I've presented this idea a couple of times, for example in a blog post:

      https://www.qt.io/blog/input-events-in-qt-6 See the section titled "Device-agnostic event handling in C++"

      When writing a new QQuickItem subclass that handles input, it's some hassle to implement both touch and mouse support, because you need to override several virtual functions and repeat the logic somewhat. And now tablet support comes into the picture too.

      In Qt 6.0 you can override QQuickItem::event() in a subclass, but then you need to handle the events that you want to handle, and delegate the rest of the events back to the superclass implementation. Maybe most Qt users know how to do that; maybe some of them will get it wrong and struggle with it. We have a tradition of using separate virtual functions for separate event types, so the QQuickItem API is quite "thick" already. I think it might be enough to add one more virtual function: QQuickItem::pointerEvent(QPointerEvent *event). This can be used to write the pointer-agnostic event handling in a subclass, by iterating points, or just looking at the first point, or the first of the points that is not yet grabbed, if you can't really handle multitouch in the subclass:

      for (QEventPoint &point : event->points()) {
            switch (point.state()) {
            case QEventPoint::State::Pressed:
              if (reactToPress(point.position()))
                event->setExclusiveGrabber(point, this);
              break;
            case QEventPoint::State::Updated:
              ...
            }
          }
      

      It needs some prototyping to see whether we can make good use of this paradigm in Controls, for example.

      But it holds us back a bit that we didn't add this virtual function yet. It's not impossible, just not very elegant to override event() itself. So this is a good candidate to go ahead and add in 6.1 if we are allowed to break BC this time.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              srutledg Shawn Rutledge
              srutledg Shawn Rutledge
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes