Rockbox

Tasklist

FS#12389 - hardware clicker improvements

Attached to Project: Rockbox
Opened by Glenn (DancemasterGlenn) - Wednesday, 16 November 2011, 14:14 GMT
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 18 January 2012, 22:39 GMT
Task Type Bugs
Category Settings
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I 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, 22:39 GMT
Reason for closing:  Fixed
Comment by Jonathan Gordon (jdgordon) - Wednesday, 16 November 2011, 22:50 GMT
I intend to fix the first issue with a nice api which the list calls. The second one is a bit harder. I made the wheel always click and regular buttons only click on the first repeat (which is what you are seeing). I'm not sure what you want from the volume wheel in the wps?
Comment by Michael Sevakis (MikeS) - Thursday, 17 November 2011, 03:32 GMT
Perhaps actions should have click-behavior mappings in the keymap? Provide a default and specify the exceptions. That way, context is always relevent. Anyway, repeats that have effects (like the volume changing on each repeat) should always register the clicks.Clicks should indicate some sort of change took place.
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 04:01 GMT
Massive overkill. But yes, some way to control click behaviour based on the context is needed.
Comment by Michael Sevakis (MikeS) - Thursday, 17 November 2011, 04:10 GMT
Overkill? It's killer!
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 04:15 GMT
Adding some flags to the returned action code might actually be doable, but it is stil a pain in the arse to implement (and needs to be fixed in every keymap file). I'd rather just do a simple api the list and wps can contorl directly
Comment by Michael Sevakis (MikeS) - Thursday, 17 November 2011, 04:35 GMT
what about all the other screens?
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 05:10 GMT
Well, what do we actually need?
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.
Comment by Glenn (DancemasterGlenn) - Thursday, 17 November 2011, 06:16 GMT
Well, in that sense, could it technically be used as a single click from, say, increasing volume, and then it would only click again if you stopped and started again, of immediately began reverse scrolling to lower the volume again? Or would said action still only be able to apply to buttons, and not the wheel behavior? Still not positive a single click is the best idea, but I do think the current behavior on volume change is less than ideal.
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 06:22 GMT
What do you actually want the volume change to do?
Comment by Glenn (DancemasterGlenn) - Thursday, 17 November 2011, 06:42 GMT
Clicking less would be better, I think. My suggestion in my last comment would make it act in a similar fashion to fast-forwarding, where it would click once on initial change, and then once more if we were "repeating", or in this case simply continuing to scroll to increase the volume. Not sure how other people would feel about it, though.

Is that more clear? I feel like I just said my last post again... maybe I'm not understanding the question.
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 06:58 GMT
ok, but hang on. Shouldnt the beep happen every time an event is triggered? so every wheel movement is a disinct action, whereas holding down the select button only clicks twice because when the second click happens it causes the repeat event and all events are ingored untill it is released. The case can be made then for holding >>| should beep every step when seeking.
Comment by Michael Sevakis (MikeS) - Thursday, 17 November 2011, 07:31 GMT
Jonathan said: "What do you actually want the volume change to do?"

Michael says, welcome or not: Make it click every time the volume changes and no more often! It should synergize the haptic intuitions. :-P
Comment by Jonathan Gordon (jdgordon) - Thursday, 17 November 2011, 07:56 GMT
I agree 100% and svn gets pretty close to that, might have a play after idnner
Comment by Glenn (DancemasterGlenn) - Thursday, 17 November 2011, 14:12 GMT
I'm more invested in the fix for the list scrolling, so however you guys decide to play the volume clicks will be fine by me. Just figured a discussion would help to decide what the ideal behavior could be. If that ends up being the current behavior, I won't turn up my nose at it.
Comment by Jonathan Gordon (jdgordon) - Wednesday, 18 January 2012, 12:22 GMT
Can this be closed now? I've got the lists working much more nicely now (since late last week i tihnk)
Comment by Glenn (DancemasterGlenn) - Wednesday, 18 January 2012, 22:26 GMT
Looks good!

Loading...