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

it's confusing that TapHandler.gesturePolicy affects event propagation

XMLWordPrintable

    • a6e196ce9 (dev), ae7069bfa (6.5), dd3484343 (6.5.0), b0bb5823e (6.4), a8fb5c36c (tqtc/lts-6.2)

      It makes a huge difference which kind of grab TapHandler takes on press. We have found some scenarios when the default policy is best, so that the event continues to propagate: for example when adding a TapHandler to an Item that already handles some events in its own ways, it's good that TapHandler doesn't interfere with that item's event handling. So it can be used to augment existing behavior.

      When using a TapHandler inside a Flickable, you might want it to take a passive grab, and while delivering subsequent move events, it then becomes important for Flickable to be able to continue filtering those, even though they are going to a handler rather than an Item (QTBUG-71918, QTBUG-73035). Or you might want it to take an exclusive grab, to avoid direct delivery of the press to the Flickable (because if that happens, the Flickable will take the exclusive grab right away).

      gesturePolicy describes an aspect of behavior at a high level, and in order to achieve that behavior, it has to do its grabs differently. But when users already know that the problem is to control whether events should keep propagating or not, they don't expect to find it in this particular property. They may start messing around with grabPermissions (but it's better to reserve that as a "last resort"), and that doesn't fix this case generally.

      So somehow we may need another property or flags to explicitly control event propagation.

      Of course people are already used to the MouseArea way: onPressed: mouse.accepted = false. But we need a declarative way.

        For Gerrit Dashboard: QTBUG-73262
        # Subject Branch Project Status CR V

            srutledg Shawn Rutledge
            srutledg Shawn Rutledge
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: