Rockbox Ports are now being developed for various digital audio players!
Out of curiosity, what if your list is short enough that 10% is actually less than 8 pages? Say your list is a mere 70 pages total? Does this mean that if you somehow trigger the last one it'll actually go slower than the previous one? Perhaps there should be a safeguard against this (though making it use a percent for both faster and fastest seems likely to do the case).
Note also that there's some sanity checking; since a percentage value for a short list can be less than a page value, it is possible that, e.g., "fastest" (hardcoded as PERCENT) might specify a scroll by fewer lines than "fast" (hardcoded as PAGE). If so, the larger of the two is used is used.And if the list is less than a screen (page) long, acceleration NEVER happens.
Out of curiosity, what if your list is short enough that 10% is actually less than 8 pages? Say your list is a mere 70 pages total? Does this mean that if you somehow trigger the last one it'll actually go slower than the previous one?
static struct scroll_accel_jump* find_accel_for_list( struct gui_list* list, struct scroll_accel_jump* jump, unsigned int raw_accel ) {// second parameter is the array of jump policies// third is the accell factor, [0..3]// find items in the list unsigned int l_items = list_items( list );// find the number of displayable lines on the screen unsigned int s_lines = screen_lines( list );// accel factor == 0 == no accel /* never accel in a list <= page long */ if( raw_accel == 0 || l_items <= s_lines ) { return jump; }// jump is the array, we're doing pointer arithmetic, // eq. to jump[ raw_accel ]// calculate_jump_lines has a side-effect: it alters its pointed-to first // param by storing the actual jump in that element's third member /* otherwise, find the highest possible accel */ calculate_jump_lines( jump + raw_accel, l_items, s_lines );// if the factor is > 1 it is "faster" or "fastest"// so calculate the next lower jump and compare them// keep doing so until you've compared to "faster" to "fast"// if the lower accel's jump is bigger, decrement the accel factor while( raw_accel > 1 ) { calculate_jump_lines( jump + raw_accel - 1, l_items, s_lines ); if( jump[ raw_accel ].lines > jump[ raw_accel - 1 ].lines ) break; --raw_accel; }// return the jump, which is the biggest jump for our accel factor// that element has been modified to also contain // the actual line count of the jump // so we can give the caller the actual jump and the policy that produced it// in case the caller wants to do something clever.// of course in any OO language this would be terrible tight coupling// but this is embedded C, different rules apply return jump + raw_accel;}
MENUITEM_SETTING(ipod_scroll_wheel_acceleration_fast, &global_settings.ipod_scroll_wheel_acceleration_fast, NULL);
INT_SETTING(0, ipod_scroll_wheel_acceleration_fast, LANG_IPOD_SCROLL_WHEEL_FAST, 135, "ipod scroll wheel fast threshold in clicks/sec", UNIT_SEC, 5, 500, 5, NULL, NULL, NULL),
MAKE_MENU(ipod_scroll_wheel_acceleration_menu, ID2P(LANG_IPOD_SCROLL_WHEEL_SPEED), 0, Icon_NOICON, &ipod_scroll_wheel_acceleration_fast, &ipod_scroll_wheel_acceleration_faster, &ipod_scroll_wheel_acceleration_fastest, );
Maybe I'm missing the point but wouldn't it be smoother/more accurate to jump by lines?As in, at "normal" one click is one menu lineAt "fast" one click is two menu lines (2x)At "faster" one click is three menu lines (3x)At "fastest" one click is four menu lines (4x).Or something like that, with 2x, 4x, 8x, etc.Seems like it would a) be FAR more consistent and b) not so jumpy since you WONT move from slow scrolling to a few pages down.
8600 items, yes, but not for most users. Because most users in Tagcache have things ORGANIZED.8600 songs? Maybe, if you feel some sort of silly urge to browse your entire collection song at a time. Take those 8600 songs and divide them up into maybe 800 Albums. 800 albums into maybe 600 artists or 20 genres. Those are the lists people work with.
TPD / Senab. Would your patch work with a REAL acceleration, rather than stepped speed increases?
Page created in 0.104 seconds with 21 queries.