This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12251 - user shortcuts in the main menu
Attached to Project:
Rockbox
Opened by Jonathan Gordon (jdgordon) - Wednesday, 31 August 2011, 17:13 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Tuesday, 15 November 2011, 14:23 GMT+2
Opened by Jonathan Gordon (jdgordon) - Wednesday, 31 August 2011, 17:13 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Tuesday, 15 November 2011, 14:23 GMT+2
|
DetailsThis adds a menu to the main menu where users can put shortcuts to any file/folder/setting.
I forgot about the existing shortcut functionality when i started this, but they are surpassed with this and should be removed if this goes ahead. file format is this: [shortcut] type: <type> where type is file, browse, setting data: <data> which is the filename/path or the setting name (from the .cfg file) name: <what to show in the menu> uses the settings menu name or the path if it isnt given I also want to add an icon and possibly colour to the item config. attached is an example shortcuts.txt file (put it in .rockbox) and the diff. This uses simplelist api which currently doesnt use the theme which should be fixed. (patch for that is in the tracker somewhere). Also need to change this to allocate shortcuts from buflib and hide the menu if it isnt being used |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Tuesday, 15 November 2011, 14:23 GMT+2
Reason for closing: Accepted
Tuesday, 15 November 2011, 14:23 GMT+2
Reason for closing: Accepted
Now we can delete all things in the main menu (of course this requires some source changing, but I think I can handle it) and rewrite the main menu with this feature.
Trying compiling for my Onda, thanks.
Also hook up the "add to shortcuts" context menu item in the filebrowser and add it to the settings menus context menu item. This doesnt save it back to disk yet though.
next step:
remove the main menu item, hook up with the .link extension so this can outright replace the current shortcuts plugin. Also add a fancy UI plugin to edit the list.
What does your different link files look like though? does each have only a few items?
I have another thought: If this core feature is aimed at having a customizable submenu of settings then it should be done and advertised as such. I can, frankly said, hardly imagine that one would want to mix links to files and links to settings in one list. What was the original idea when you implemented the feature? Did you want to have a customizable settings menu, and links to files were added at almost no additional cost?
1) people wanted a better QS with more than 4 items
2) people have wanted to be able to run config files from the QS
3) people wanting customisable menus
Like I said, I forgot about the shortcuts plugin when I started this but i'd like to make it a replacement if we can sort out the use cases I'm breaking.
I'm using buflib for shortcut storage in ram so one possible way to do this is make this the "viewer" for the .link files (format changed though so maybe link2?) and keep all loaded shortcuts in ram as used but only show the ones from the file that was actually loaded? (amybe with a toggle to show all).
If your argument is that the functionality overlaps the quickscreen functionality and therefore only one is needed, I could argue that the quickscreen functionality overlaps with the settings menu, so it should be removed.
I think the proposed menu is sufficiently different from the quickscreen to warrant having both.
Another question: is it possible to add a file / a dir to the list directly from the browser? Or is it only possible through editing a file?
I can very easily add divider items to help make the list nicer to view and it already has icon support so it should be very easy to find the item you want *quickly*.
Also bear in mind this patch adds 2.5K to the mini2g binary already and I dont want to add too much more.
bah, nice timing :)
that answers your first question.
I've taken over the "add to shortcuts" context menu in the browser to auto add, and added it to the context menu hit from the settings items in the menus.
This all is aimed at minimizing the size delta.
so then it becomes a question of how to work this towards commiting with minimal fuss. Possibly use .link2 for the extension which wont interfere, or see how much immediate opposition there is to the main menu item that this patch already does, or look into allowing the user to set this as the QS instead of the current one.
BUT, I'm not interested in this discussion *here*... that goes in the mailing list.
And: we need a manual entry :-)
the following shortcut types are supported:
'browse' - open the filebrowser with a specified file/folder selected
'run' - Open a specific file with the default action (start playback with a .mp3, open a .txt file, load a .cfg config, etc)
'playlist menu' - open the filetrees "Add to current playlist" context menu on a specific file/folder
'setting' - open the setting changer screen on a setting
'debug' - open one of the debug menus
'seperator' - do nothing, display a line of text (or blank even)
All items can be given a icon (uses a default for each type if one isnt speficied in the shortcuts.txt file), use "icon: <number>" to specify
All items will display something default unless the "name: foo" is specified
All but 'seperator' use "data: foo" to specify the thing to work on, for setting it it the config name, for debug it is the menu item name (as displayed in the debug menu), for the others it is the full path.
A 'browse' shortcut for a folder without the trailing slash (i.e data: /music/foo) will put the selection on the foo item in the browser. *with* the trailing / the filebreowser will be *inside* the /music/foo folder
Easiest way to deal with shortcuts is to add them manually from the items context menu and then modify the shortcuts.txt file later. There is currently no way to reload the shortcuts.txt file after it is loaded the first time (first time the shortcuts menu item is entered) but any items added since the file read will be in the menu anyway.
On my local tree I've got a call to shortcuts_init() before the main menu loads so playback doesnt pause the first time it is entered. I'm not sure if that is something which we want in svn or not (if this is accepted).
It is great idea. For me and for my blind friends it will be very useful. For example now I thinking about how to solve that the section Time and Date was moved from menu System to deep of Settings menu and function long press of any item in this sub menu (saying actual time and date) is start practically unusable. If it possible to set this function to sub menu Shortcut it will be great.
fml: Na, I didnt use the .link extension so old ones will just keep working
Hoping to commit relativly soon, manual doesnt need to be done immediatly I tihnk.