Repository navigation
Some event kinds shouldn't allow non-zero pressure #30412
Description
Reasoning
Currently most pointer event classes accepts a parameter pressure in their unnamed constructors and pass it to their superclass PointerEvent. This allows them to have non-zero pressure, which however doesn't always makes sense. More specifically, a non-zero pressure indicates that the pointer is in contact with the screen with certain force. The following table lists all event types and whether they are supposed to have a non-zero pressure:
| Pointer event kind | Does non-zero pressure make sense? |
|---|---|
PointerAddedEvents |
No. This event indicates the start of the device tracking the pointer, which should contain no movement. |
PointerCancelEvents |
No. This event indicates the end the pointer being directed towards this device, which should contain no movement. |
PointerScrollEvents |
No. It's a pointer signal and doesn't change the state of the pointer. |
PointerSignalEvents |
No. Pointer signals doesn't change the state of the pointer. |
PointerUpEvents |
No. The pointer has stopped making contact with the device, hence the pressure must be zero. |
PointerMoveEvents |
Yes. The pointer is moving while in contact with the device. |
PointerDownEvents |
Yes. The pointer has made contact with the device. |
PointerExitEvents |
No. This event only includes situations where the pointer is not in contact with the device. |
PointerEnterEvents |
No. This event only includes situations where the pointer is not in contact with the device. |
PointerHoverEvents |
No. The pointer is moving while not in contact with the device. |
PointerRemovedEvents |
No. This event indicates the end of the device tracking the pointer, which should contain no movement. |
This parameter was brought in by #24554, which added pressure to every pointer event classes to support force press gesture. According to discussion, this change was questioned (here among many others) at first, but eventually made it due to miscommunication. A later PR which added Enter and Exit likely followed the same pattern for consistency.
Changes
We propose to remove pressure from the unnamed constructors of the following classes:
PointerAddedEventPointerRemovedEventPointerHoverEventPointerEnterEventPointerExitEventPointerUpEventPointerCancelEvent
Instead, each class will pass pressure = 0.0 to its superclass.
A proposed PR can be found at #30414.
Impact
This change will break code that explicitly creates an instance of the aforementioned classes and specifying pressure.
To migrate the affected code,
- If your constructor has pressure = 0.0, simply remove this argument and the behavior will be the same.
- If your constructor has a non-zero pressure, migrate based on why it was needed. For example,
- A
PointerHoverEventin this way is likely a misuse fromPointerMoveEvent, which is defined as moving while the pointer is in contact with the device (per class documentation), where a non-zero pressure makes sense. - A
PointerAddedEventin this way should be expanded into anAddedfollowed by aDownwith the requestedpressureanddown. - A
PointerRemovedEventorPointerCancelEventin this way should be expanded into aMovewith the requestedpressureanddownfollowed by aRemovedorCancel.
- A
This change will not break code that uses events dispatched by Flutter framework, including all gestures.
Activity
JediBurrell commentedon Apr 3, 2019
It currently takes all mouse events, as with the
downproperty, which would explain it. I see it more of ascalesituation, where this callback overridesPointerMoveEvent(though this is not mentioned). Unless I'm misinterpreting it, this seems intentional.dkwingsmt commentedon Apr 3, 2019
Sorry, I don't quite get you, can you elaborate?
As far as my understanding of your point,
PointerHoverEventdoes not allow customization ofdown, instead setsdown = false.[-]PointerHoverEvent shouldn't allow non-zero pressure[/-][+]Some event kinds shouldn't allow non-zero pressure[/+]JediBurrell commentedon Apr 4, 2019
Upon further looking, I can see I was indeed misinterpreting it. I could have sworn
downreturned its value, but you're right. My apologies.github-actions commentedon Aug 30, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.