|
Rockbox mail archiveSubject: Request for comments on Ipod scroll wheel accelerationRequest for comments on Ipod scroll wheel acceleration
From: <postmaster_at_diffenbach.org>
Date: Thu, 08 Jun 2006 21:51:17 -0400 Request for comments on Ipod scroll wheel acceleration Scope: Ipod Video targets, possibly other Ipod targets. Chris Russell offers a patch, http://www.rockbox.org/tracker/task/5377 , to handle accelerated scrolling for the Ipod. In this document, I propose a different method for handling accelerated scrolling. This is not a matter of Russell's code being bad -- it's pretty clean --, it's as a matter of how it interacts with the existing code base. Russell's initial patch establishes two new virtual keys, one each for accelerate scrolling backward and forward. His revised patch establishes eight, four each for accelerated forward and accelerated backward scrolling. Because these new keys are not "or'ed" together with the existing BUTTON_SCROLL_FWD or BUTTON_SCROLL_BACK keys, these key presses are effectively "invisible" to any existing code that processes keys, until and unless the existing code is changed to recognize the new keys. If an accel key is generated, to unmodified code it's as if no key had been pressed. This is particularly burdensome for plugins: either plugin authors, who themselves may not own an ipod, must add ipod-specific key-handling code, or risk the plugin "not seeing" the standard key when an accel key is generated. A better alternative would be to "or" the acceleration key together with the standard BUTTON_SCROLL_FWD/BACK key. However, since much of the existing code base switches on the actual button value, without masking off the bit of interest, i.e., code-base is: switch( button ) { //... case BUTTON_SCROLL_FWD : code-base is not: if( button & BUTTON_SCROLL_FWD ) { this strategy also "breaks" existing code. To allow both acceleration and backward compatibility of existing code, I propose that, as currently, only BUTTON_SCROLL_FWD and BUTTON_SCROLL_BACK be generated. (These map to the standard BUTTON_DOWN and BUTTON_UP respectively.) However, for ipods only, I suggest adding the function enum wheel_accel get_ipod_scroll_wheel_acceleration( void ) ; where wheel_accel is enum { NORMAL, FAST, FASTER, FASTEST } wheel_accel ; declaring it in button.h and defining it in button.c Existing code would continue to function normally, but could be modified (for ipod only) to call get_ipod_scroll_wheel_acceleration() where desired. Plugins or code unconcerned with acceleration would continue to function as expected, without modification. This abstract interface also allows acceleration to be implemented in a number of different ways. I've currently implemented three forms: *acceleration based on "winding" the wheel, that is the number of times the wheel has been "rotated" 360 degrees without the user's finger lifting or reversing its direction; * acceleration based on in which of four sectors the finger initially touches the wheel (0-89 degrees is normal, 90-179 is FASTER, etc.); * acceleration based on the actual finger speed (delta of finger position) Potentially, any of these forms could selected by user preferences (or by patching), while keeping the same public API, get_ipod_scroll_wheel_acceleration. (Another alternative would be for client code to examine the "data" field in the button queue, which records the absolute wheel position and the delta, if any, since the previous button). However, this puts the burden on client code outside of button.c to understand these values, inviting inconsistency as different code sites may evaluate these raw values differently. It also requires multiple code sites to find the /previous/ queue element, wrapping around if necessary. And it doesn't allow for different GUI methods to establish when, and to what extent, acceleration is in effect. Using the abstraction of a public function makes everything clearer, more consistent, and easier on client code.) Your comments are requested. Received on 2006-06-09 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |