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

Get rid of QQuickMouseEvent signals in Controls; make sure pointer handlers are a good substitute

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • Not Evaluated
    • None
    • None
    • Quick: Controls 2
    • None

    Description

      TextArea has

          void pressAndHold(QQuickMouseEvent *event);
          // 2.1 (Qt 5.8)
          Q_REVISION(2, 1) void pressed(QQuickMouseEvent *event);
          Q_REVISION(2, 1) void released(QQuickMouseEvent *event);
      

      and QQuickMouseEvent is just not the way to go here for several reasons:

      • we invite the user to write a JS handler instead of declarative QML
      • the user needs to know low-level details about when to ignore the event to let it keep propagating
      • QQuickMouseEvent is not the right type to handle touch or tablet events
      • QQuickMouseEvent doesn't have a QPointingDevice, so the user doesn't have that mechanism to disambiguate event types
      • legacy Controls code didn't even bother setting QQuickMouseEvent::source(): hard to believe, but true
      • functions like QQuickTextArea::mousePressEvent(QMouseEvent *) rely on touch->mouse synthesis instead of handling pointer events directly

      Removing these will probably allow us to remove quite a bit of (buggy) event-handling code, and even the QQuickPressHandler struct, which seems to be only used in TextArea and TextField. And we will get better separation of concerns: TextArea's concern is text editing, not running its own timer for the long-press, popping up context menus, and whatever else these ugly JS functions would get used for in the real world.

      But since they have been there until now, we'll have to deprecate them first. Hopefully it will turn out that there aren't too many users, and nobody gets too vocal about not being able to control event propagation if we take away the ability to set the accepted flag directly. But for the simple case of handling right-clicks and long presses, a TapHandler should be a much better fit... after QTBUG-101398 is fixed. And ideally you would not need to set both gesturePolicy and grabPermissions, either.

      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:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes