Bugzilla – Bug 7292
Hotkeys should be manually associated with favorites
Last modified: 2009-07-31 10:17:37 UTC
At the moment, hotkey numbers 1-9 and 0 are automatically associated with the first 10 favorite items. When a favorite is moved to re-order the list or a favorite is deleted, other hotkey numbers can be affected. This is often undesirable. I suggest that hotkey numbers should be manually assigned to favorites. The hotkey number would stick to the chosen favorite, unless unassigned (or the favorite is deleted) or reassigned manually to another favorite. When editing a favorite item, a hotkey number could be chosen from a drop-down list that lists all currently unassigned hotkeys, or blank to remove the association. This should be available on any favorite item that can be used from a hotkey. Pressing the hotkey associated with a favorite song, album, year or URL would cause a play action, whereas favorite sub-folder should cause a browse action (navigate to that sub-folder).
This would also solve one of my other issues. At the moment, with automatic associations, I can't use hotkeys for the first 5 favorites, or the 10th favorite. I use TrackStat plugin to rate songs, so keys 0-5 are used to make this rating. Therefore, I wouldn't want to associate any favorites to hotkeys 0-5. The only small side effect of the hotkeys being manually associated with favorites, would be that a user that predominently uses the remote would not be able to assign hotkeys. This isn't so bad, because current a user cannot re-order favorites to control the automatic hotkey associations from the remote anyway. An additional enhancement could be therefore that a new favorite added from the remote gets the next available hotkey number.
We'll look at this post 7.0.
Created attachment 3059 [details] initial patch to store hotkeys separately from opml index Attached path will allow the hotkeys to be set separately from the opml index. We need to discuss what the user interface is for this. On the player (button) interface there is probably a need to change the hotkey value, should this also be available on the web interface?
> should this also be available on the web interface? I could see myself using the hotkeys, probably for radio stations, but I'd want to manage them only from the web interface. The thing I've wondered about manually associating keys to favorites is how you'd deal with overwriting those that already exist. In the web interface you might indicate when the user is associating an already used key (I was thinking you'd use a drop-down) and show which of the keys are already in use with an asterisk. 1* 2* 3* 4 5* 6 7 8 9 0
My concern with hotkeys for favorites is that they are in contention with other plugins that map functions to those keys. Eg. TrackStat uses digits 1-5 and 0 for setting the rating on the currently playing track. There are other plugins that can attempt to register functions for these remote buttons too. Is there really a need for hotkeys? The SBC doesn't have buttons for digits 0-9. I've never bothered with them. How much hassle is it to navigate to favorites and play a favorite from there? Maybe a plugin could be written to handle the association of buttons to favorites, and that could add the UI settings page as a per-player setting page. In fact, taking it a step further it could be a general keymap editor to create/edit any .map file, so if another plugin registers a function for a key, it would be visible in the editor.
I've added the patch above to 7.1 in change 18472 - please try it out and comment back on it. At present there is no web interface to change assigned hotkeys, these are assigned from the freely available hotkeys when a favorite is created from the button mode interface and are never changed. Needs a web interface as defined by Jim - this is work in progress...
Created attachment 3236 [details] web editting of hot keys Patch to add hotkey editing to web interface - along lines of Jim's comment. Michael - this does not look very good - could you make it look nicer? The "*" indicates that the key is already used. I think it would be nice if we could grey out used items rather than do this. Also it would be nice if the list was thinner - is this possible?
I tried this patch with 7.2 (it merged OK) and don't get anything in the drop downs. Also, the dropdown doesn't show up when creating a new favorite. I like the idea of graying used items, but they still need to be assignable. One other thing to look at while styling the edit form is what happens to the form layout and buttons when the left windows is relatively small. The input fields and buttons themselves appear to get smaller. For text input fields this may be OK, but you don't really want buttons reading 'Sav' and 'Can'. I'd consider always placing them on a 2nd line below the input fields.
Sorry Triode for keeping you waiting - and thanks Jim for adding me to the list. Will take a look at it. Will assign back to you when I get stuck ;-)
Triode - is there a simple way I could have a favorite's title with every hotkey in the web interface?
change 19318 - display assigned stations when opening the list, but only show the number when closed. Will give the buttons some love later.
I am on latest SVN 7.1/trunk (08/05/2008). Nothing happens when I click on the edit favorites icon in the default skin. [21:53:05.9357] Slim::Networking::Select::select (245) Error: Select task failed: Can't locate object method "hotkeys" via package "Slim::Plugin::Favorites::OpmlFavorites" at P:/Music/SlimServer/trunk/server/Slim/Plugin/Favorites/Plugin.pm line 687.
Phil - do you have a full checkout of the latest svn? The hotkeys method is definately there and working for me. Its checked in: http://svn.slimdevices.com/7.1/trunk/server/Slim/Plugin/Favorites/OpmlFavorites.pm?view=log
I have http://svn.slimdevices.com/repos/slim/7.1/trunk/server 19607. except I have applied a local edit to Slim/Utils/PluginManager.pm to allow 7.0a1 plugins to run under 7.1.
I also see the following several times in the log before the error messages: [21:06:10.0025] Slim::Utils::Misc::msg (1329) Warning: [21:06:10.0019] Use of uninitialized value in concatenation (.) or string at P:/Music/SlimServer/trunk/server/Slim/Networking/Discovery.pm line 157. [21:06:10.0031] Slim::Utils::Misc::msg (1329) Warning: [21:06:10.0027] Use of uninitialized value in addition (+) at P:/Music/SlimServer/trunk/server/Slim/Networking/Discovery.pm line 169. [21:06:10.0036] Slim::Utils::Misc::msg (1329) Warning: [21:06:10.0033] substr outside of string at P:/Music/SlimServer/trunk/server/Slim/Networking/Discovery.pm line 169. [21:06:10.0040] Slim::Utils::Misc::msg (1329) Warning: [21:06:10.0038] Use of uninitialized value in subtraction (-) at P:/Music/SlimServer/trunk/server/Slim/Networking/Discovery.pm line 170.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC