Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: RE: Hotkey patch

RE: Hotkey patch

From: Scott Berry <scottbb1973_at_gmail.com>
Date: Sun, 28 Mar 2010 12:53:50 -0500

Hey there,

 

A confirmation would be good for this because if on the blindness side
someone hits a key unintentionally then oops what did I hit!!! Sounds like
something I've done before.

 

 

 

  _____

From: rockbox-dev-bounces_at_cool.haxx.se
[mailto:rockbox-dev-bounces_at_cool.haxx.se] On Behalf Of Paul Louden
Sent: Saturday, March 27, 2010 18:49
To: Rockbox development
Subject: Re: Hotkey patch

 

On 3/27/2010 6:46 PM, Jeff Goode wrote:

In a couple of different screens, the button I'm using was already assigned.
But in one, the bookmark menu, it acts the same as before, with a delete
prompt. It's not assignable, just internally renamed. In the other, the
WPS, the button was hardcoded to show the playlist. That's still the
default behavior, but it can be assigned to another function if desired. I
tried to make it so that nothing changed without the user's deliberate
action. If you didn't know hotkeys existed, you should be able to continue
blissfully unaware of their existence. Unless you assigned a hotkey by
accident. But since you can do that only within a context menu and requires
a keypress that isn't currently valid, that doesn't seem very likely.

Maybe a confirmation prompt when changing it? Some people currently use that
"unassigned" keypress to trigger the backlight if it fades (since it still
does that) and might not realize they're assigning the key to a role.
Received on 2010-03-28


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa