I like the idea of f1=rocbox menu; f2=custom menu; f3=context menu
many complain <this> option or <that> option should be in the top level menu - a custom menu would allow people to have their favourite options within easy reach
hmmm, but I would still like to find (personally) sleep-timer and backlight-timer a quick step away wherever I am
hmmm, not sure I agree, but I'm not sure why - it seems sensible to have context-menu defined by Rockbox - example, if context on a file, is "sleep-timer" in context?
c0utta here: it's on this basis that I've developed the NEWKEYS functionality. F2 is a custom menu and F3 is context sensitive. I have been using the code on my JB for 3 months now, but I only have a very limited set of actions that I use personally, so I haven't fully developed every action. After discussion with the core developers, I have hardcoded the F3 context menu.
let's say the context menu _is_ provided by rockbox - but at the same time being user customizable throuh a config file...
Q: from a support point of view, i think this will make life difficult
A: maybe - or maybe the users requiring support would not be clever enough to start and modify the default menu config file
c0utta: the functionality I've developed uses a CFG file to create the custom menu, and I have also proposed that F3 should be able to be defined. For example, I personally use none of the playlist options and don't really want to see them on my context menu. I know I'm in the minority here...
Q: so if I want sleep-timer, I just add it to all 10-or-so custom menus?
A: no, the sleep timer would probably be there already in the Track screen (WPS) - but let's say you want it accessible from the context menu in the playlist screen - then you would add it there
Q: where would something like Disk Spin Down be?
A: I think there would still be a "System menu" but it would be a bit more difficult to get to, e.g. requiring two keys, or holding down a key
currently rejected in favour of a more classic menu list