Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Settings
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.9
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by DancemasterGlenn - 2011-11-16
Last edited by jdgordon - 2012-01-18

FS#12389 - hardware clicker improvements

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!

Closed by  jdgordon
2012-01-18 22:39
Reason for closing:  Fixed

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?

MikeS commented on 2011-11-17 03:32

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.

Massive overkill. But yes, some way to control click behaviour based on the context is needed.

MikeS commented on 2011-11-17 04:10

Overkill? It's killer!

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

MikeS commented on 2011-11-17 04:35

what about all the other screens?

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.

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.

What do you actually want the volume change to do?

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.

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.

MikeS commented on 2011-11-17 07:31

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

I agree 100% and svn gets pretty close to that, might have a play after idnner

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.

Can this be closed now? I've got the lists working much more nicely now (since late last week i tihnk)

Looks good!

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing