Closed Bug 933236 Opened 11 years ago Closed 10 years ago

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

Categories

(Core :: Panning and Zooming, defect)

26 Branch
x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jimm, Unassigned)

References

Details

(Whiteboard: [feature] p=0)

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.
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.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Whiteboard: [release28]
This doesn't block, we can continue to use the winrt gesture recognizer for this until we get around to fixing this bug.
Whiteboard: [release28]
How do we distinguish between "doesn't block" and "hasn't been triaged"?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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].
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.
Blocks: metrobacklog
No longer blocks: metro-apzc
Whiteboard: [feature]
Whiteboard: [feature] → [feature] p=0
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.