This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12389 - hardware clicker improvements
Attached to Project:
Rockbox
Opened by Glenn (DancemasterGlenn) - Wednesday, 16 November 2011, 15:14 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 18 January 2012, 23:39 GMT+2
Opened by Glenn (DancemasterGlenn) - Wednesday, 16 November 2011, 15:14 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 18 January 2012, 23:39 GMT+2
|
DetailsI didn't make it back to the tracker issue before the piezo driver was committed! Bah. I tested out the version in SVN (thanks jdgordon!), and had some suggestions for improving it. Others may have things they wish to bring up, so I made the title more ambiguous.
At some point something must have changed in the upped patches on flyspray, because I noticed one nice change missing in SVN: previously, if one scrolled to the bottom of a list with keyclick on, and continued to scroll, the clicking would stop (as movement has done). This was a good way to tell a user they were at the bottom of a given list, for obvious reasons. Currently the version is svn will continue to click away, which may be less than ideal. Is this something that could be "fixed"? Clicks stop if one reaches the top of bottom of a list with continuous scroll? The code is somewhere on the old task, so if it is desired, it would hopefully be on the easy side to implement. Hope others will feel the same about the idea. The only other thing I wanted to bring up was that clicks in the Now Playing screen may not be as-desired.Fast-forward and rewind are lovely... just two clicks, probably a product of my having repeats off. Volume change is just kind of a mess of clicks... maybe it should have a specific behavior unto itself? We tried a couple of things in the old task that seem to have also fallen by the wayside, but it might be worth looking into. maybe less frequent clicks on volume change actions? Or implementing a single click on first adjustment of volume, just so the user knows that the volume action is triggered? I'm just spitballin, here. :) Anyway... hope that these points will be considered. If either sounds particularly bad, feel free to add your two cents. Thanks, guys! |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Wednesday, 18 January 2012, 23:39 GMT+2
Reason for closing: Fixed
Wednesday, 18 January 2012, 23:39 GMT+2
Reason for closing: Fixed
I was initally thinking just a simple clicker_inhibit_action(int action) which would block any clicks on a specific action untill some other action is pressed. i.e in the list, if you are at the top then any action except ACTION_STD_PREV_REPEAT should still click.
Is that more clear? I feel like I just said my last post again... maybe I'm not understanding the question.
Michael says, welcome or not: Make it click every time the volume changes and no more often! It should synergize the haptic intuitions. :-P