This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11081 - Adds user programmable hotkey to context menus
Attached to Project:
Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Saturday, 06 March 2010, 18:33 GMT+2
Last edited by Jeffrey Goode (Blue_Dude) - Thursday, 01 April 2010, 05:21 GMT+2
Opened by Jeffrey Goode (Blue_Dude) - Saturday, 06 March 2010, 18:33 GMT+2
Last edited by Jeffrey Goode (Blue_Dude) - Thursday, 01 April 2010, 05:21 GMT+2
|
DetailsThis is a work in progress. This first patch shows how the interface would work on the e200 target only. The hotkey selected for the e200 is short-REC, which was the key used in the bookmark menu to specify the delete function. So far, the hotkey doesn't do anything except show a splash message, except in the bookmark menu, which works as before.
The goal is to allow the user to drill down to the context menu with the context menu button, scroll to the function intended for the hotkey, then press the context menu button again to assign that function to the hotkey. Then, the user could press the hotkey button on an item rather than the context menu button to perform that function. The hotkey assignment would persist between session, and would vary by context menu. Comments are appreciated. 
hotkey_test.patch
(7.1 KiB)
apps/action.h | 2 +- apps/tree.c | 9 +++++++-- apps/onplay.c | 15 +++++++++++++-- apps/gui/wps.c | 8 +++++++- apps/onplay.h | 2 +- apps/bookmark.c | 4 ++-- apps/keymaps/keymap-e200.c | 9 ++------- apps/playlist_catalog.c | 8 ++++++-- firmware/export/config/sansae200.h | 2 ++ 9 files changed, 41 insertions(+), 18 deletions(-) |
This task depends upon
Closed by Jeffrey Goode (Blue_Dude)
Thursday, 01 April 2010, 05:21 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as r25414
Thursday, 01 April 2010, 05:21 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as r25414
FS#5555) but maybe opinions have changed since then.FS#5555. I sure would like to know why it was ultimately rejected.I forgot to mention that a couple of versions back I made the hotkey assignment key the same as the hotkey itself. So to assign a hotkey, go into the tree or WPS context menu, scroll to the function you want to assign and press the hotkey. If it's an acceptable assignment, the splash will confirm the new assignment. If not, the splash will say that the hotkey is Off and the assignment will be cleared. Assignments are permanently saved.
Also, I dont tihnk the assignemnt should persist over boots.
These additions cost quite a bit of bin size though: about 600 bytes.
To assign hotkeys, I used the existing keypress in WPS for View Playlist, which the hotkey replaces. If that keypress could be assigned to the tree hotkey without conflict, I copied it. If not, I put in a commented out placeholder for future assignment. If both the WPS and tree hotkeys were valid, I switched on the hotkey in the associated config file. If not, I put in the lines but commented out the define.
There are several targets that can support hotkeys but there was some kind of conflict that prevented me from making a valid assignment. Changing existing key assignments to clear the conflict should be a group effort. And there were several targets that didn't support View Playlist and I didn't try to go further without more target specific information. Those keymaps were unchanged and their configs switched off.
My idea was to ACTION_WPS_VIEW_PLAYLIST (and the case in wps.c) and to put the code of the ACTION_WPS_VIEW_PLAYLIST case into the ACTION_TREE_HOTKEY case. Basically let ACTION_TREE_HOTKEY replace ACTION_WPS_VIEW_PLAYLIST no matter of HAVE_HOTKEY being defined or not.