933236 - GestureEventListener should use gesture related system settings on platforms that support them

Status: RESOLVED INCOMPLETE

(Core :: Panning and Zooming, defect)

Description

[Jim Mathies [:jimm]]

GestureEventListener currently uses a set of internal constants for short/long/double tap durations. On Windows these durations should come from the system since they can be changed by the user via the control panel.

For the time being metrofx is using the winrt gesture recognizer to work around this.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Is it a feasible approach to ensure that all of these values are controllable by prefs, and then have the winrt widget code twiddle the prefs as needed? Presumably there's some way to listen for changes in the system settings that control these durations.

If that doesn't work then the sanest option is to not use GestureEventListener on winrt and pipe in your own gesture events to the APZC.

Comment 2

[Jim Mathies [:jimm]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> Is it a feasible approach to ensure that all of these values are
> controllable by prefs, and then have the winrt widget code twiddle the prefs
> as needed? Presumably there's some way to listen for changes in the system
> settings that control these durations.
> 
> If that doesn't work then the sanest option is to not use
> GestureEventListener on winrt and pipe in your own gesture events to the
> APZC.

Yes we can use nsLookAndFeel if we think the value is something the user might want to customize for the app.

Comment 3

[Jim Mathies [:jimm]]

This doesn't block, we can continue to use the winrt gesture recognizer for this until we get around to fixing this bug.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

How do we distinguish between "doesn't block" and "hasn't been triaged"?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> How do we distinguish between "doesn't block" and "hasn't been triaged"?

Currently an empty white board indicates that. We just have to be careful about marking [triage]/blocking flags on any new bugs we file. Alternatively we could start marking non-blocking with something like [notblocking].

Comment 6

[Allison Naaktgeboren :ally]

noting that when this is implemented, the doubletap to zoom code will likely need to be modified. Bug 895581 has some wip patches that might be useful in that case.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

There is nothing that needs to be done on this big at this point since we're not working on metro. Closing for now; we can revisit this issue if necessary for APZ on desktop.