Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category User Interface
  • 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 jdgordon - 2011-08-31
Last edited by jdgordon - 2011-11-15

FS#12251 - user shortcuts in the main menu

This 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

Closed by  jdgordon
2011-11-15 13:23
Reason for closing:  Accepted

Great work! We maybe can use it to re-form the hole menu in Rockbox later. Just delete out what we don’t want.
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.

Add support for setting the item icon (defaults to no icon). file and browser type allow for “icon: filetype” which will use whatever icon the file would get in the file browser. or use a number (0-~32 iirc)
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.

Fix it so it writes the items added from the context menus back to disk. Use buflib for shortcut storage so we dont waste ram fr those that dont want it.

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.

forgot to attach the patch apparently

fml2 commented on 2011-09-04 15:29

While it may be a nice feature to have shortcuts to settings, I think that the shortcuts plugin has a big advantage over the proposed core implementation: with the plugin, you can have many .link files in many places. I do have a couple of them – grouped by “genre”. I I understand correctly, this would not be possible with this patch.

that is correct in the patch as it is, but that can possibly be changed.
What does your different link files look like though? does each have only a few items?

fml2 commented on 2011-09-05 06:42

All .link files have the same syntax. And yes, I have a couple of files with only a few items in each, just as a mean to jump to one of frequently used folders.

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?

My origional motivation was this:
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).

fml2 commented on 2011-09-05 09:24

Then I think this patch should be discussed more (and will eventually end in an endless argument ;-), since its primary purpose is quick screen replacement / enhancement. Shouldn’t we drop the one we have now if this patch goes in? The point 3) is not solved by this patch IMO, because the patch only offers a very limited customization. Well, quick screen *is already* a customized menu, since you can choose what items you want to have there. The patch only changes what it looks like and what can be placed into the quick screen. So now I even think that the title of this FS task should be adjusted.

well put it this way. I’m putting the patch up because i tink its a fun thing to do, I have no intention of having a fight over it so if someone else wants to push for it to be commited so be it. I dont really see why this cant be finished as a replacement for shortcuts.rock though as it is an improvement over whats currently available.

Admin
fg commented on 2011-09-05 09:43

I’m not sure if the perceived limitations of the quickscreen being a motivation means that this is intended to outright replace the quickscreen.

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.

I said this should replace the shortcuts.rock. I’ve said numerous times in irc that any QS changes i’m tihnking about would be either/or user selectable. not an outright replacement

fml2 commented on 2011-09-05 14:20

OK, I’m not against the feature. But would it be possible to support multiple shortcut files?

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?

Ok, skipping over the last comments… I reckon I can add mulitple file support pretty easily, but I wonder how many people actually really want that? even if the list has to scroll a screen or two it is still faster to go throuh this than to go through the file browser, find the .link, run it, then find the item you want and OK that.
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.

fml2 commented on 2011-09-06 06:19

OK, I can live with the shortcuts implementation in the core even if it only allows for one file. But then we could leave the viewer part of the shortcuts plugin and thus support multiple .link files. They will just need to be created manually. Or we can adjust the shortcuts viewer to support the new format as well.

This all is aimed at minimizing the size delta.

Well this is hardcoded to using /.rockbox/shortcuts.txt so there is no real reason .link needs to be used. The issue will be though that I’ve repurposed the context menu “add to shortcuts” item. Though that menu only works for a hardcoded shortcut file also so this doesnt change anything.
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.

fml2 commented on 2011-09-06 06:53

I’m not against the patch as it is now. I only wanted to say that committing the patch does not necessitate throwing away the viewer part of the shortcuts plugin. The “writer” part becomes obsolete.

And: we need a manual entry :-)

Big update, bugfixes and new features:
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.

Not entirely sure what’s new in this one, mostly bug fixes.
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).

fml2 commented on 2011-11-01 17:00

Shouldn’t it read “sepArator” (not “sepErator”)?

probably :) I’ll fix that tonight

fml2 commented on 2011-11-02 10:46

Otherwise I like the features and the patch. But I still think that the old shortcuts plugin can stay since it has some features this patch does not have. The context menu “Add to shortcuts” would of course “link” to the new feature; the old plugin would have to be started via the context menu “open with…”

Hi.
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.

I’ll have a think about it. The shortcut items don’t currently talk so thats something I’ll also need to look at adding.

fml: Na, I didnt use the .link extension so old ones will just keep working

fml: Here is the manual entry, if you could please turn it into something resembling TeX :)

Hoping to commit relativly soon, manual doesnt need to be done immediatly I tihnk.

fml2 commented on 2011-11-14 20:00

What about renaming ‘sepErator’ to ‘sepArator’?

fml2 commented on 2011-11-14 22:07

Here’s the manual entry formatted as LaTeX. I can’t tel whether the contents is correct. I only did the formatting and rephrased some places. Please read and tell what’s wrong :-)

I fixed that typo alrready :) thanks for that.

fml2 commented on 2011-11-15 08:37

In the latest attached code patch I still see “[SHORTCUT_SEPERATOR] = “seperator”“. Or did you fix that in your git branch (which I have not looked at)?

yes, fixed locally

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing