I'd like to discuss this more.  Can you give concrete walkthroughs of how it would be used? 

*** Bug 6022 has been marked as a duplicate of this bug. ***

*** Bug 6055 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> I'd like to discuss this more.  Can you give concrete walkthroughs of how it
> would be used? 
> 

The "ContextMenu" button in the text below can be accessed by holding one of the existing buttons down for a while or by adding a completely new hardware button on the remote. If not adding a new button to the hardware I would suggest that either "middlebutton-hold" or "play-hold" would be the "ContextMenu" button. It's not important how it's launched, but it is important that it is launched from the same button combination everywhere in the interface.

Here are some scenarios:

Sample 1:
=========
1. The user navigates and selectes "Music Library/Artists/Metallica"
2. The user now have a number of options:
- Hit "Play" to start playing all Metallica
- Hit "Add" to add all Metallica to current playlist
- Hit "Middle button" to view the albums of Metallica
- Hit the "ContextMenu" button to show the context menu
3. When hitting the "ContextMenu" it would in this case show a menu that contains items like:
- Play artist
- Add artist
- View albums
- View songs
- Create MusicIP mix
- Remove arist from playlist
- Rate artist
- View statistics

(The "Create MusicIP mix" is provided by the MusicMagic plugin and the "Rate artist" and "View statistics" items would be provided by the third party TrackStat plugin)

Sample 2:
=========
1. The user navigates and selectes "Now Playing/1. Enter Sandman by Metallica"
2. The user now have a number of options:
- Hit "Play" to start playing "Enter Sandman" song
- Hit "Middle button" to view song details of "Enter Sandman" song
- Hit the "ContextMenu" button to show the context menu
3. When hitting the "ContextMenu" it would in this case show a menu that contains items like:
- Play Song
- Move last
- Remove song from playlist
- View song details
- Create MusicIP mix
- Rate song
- View statistics
- Clear playlist
- Add to zapped playlist

(The "Create MusicIP mix" is provided by the MusicMagic plugin and the "Rate artist" and "View statistics" items would be provided by the third party TrackStat plugin)

Principles:
===========
The principles is that the context menu should be available everywhere where an object is selected. An object might be an "artist", "album", "song", "genre", "year", "playlist" or any other kind of object.
A context menu item provider would register the menu items it like to add to all relevant object types. As an example MusicMagic plugin may like to add menu items to the object types "album", "artist", "song" while another plugin only like to add items to the context menus shown when launched from a "genre" object.
When registering a context menu item, I think it might be a good idea to be able to specify an area where the menu item should be shown. For example, I think one might like to have a bit different menu items when launching the ContextMenu for a song from current playlist compared to when launching it for a song from the browse menus. As an example the "Move last" action or the "Clear playlist" action may not make much sens in the browse menus, but it does in the current playlist.

I think it would be a good idea if it was possible to tag the current items with an object type, this way the functionality could also be available for custom object types not normaly supported in SqueezeCenter, for example in plugin specific menus. This could be object types like "style", "mood", "decade" and "internetradiostation". As an example, when moving into the "Music Library/Artists" menu, all menu items would be tagged as "album".

When a context menu item is selected by a user, it would launch a callback. In the Jive interface I suppose a callback would mean that the plugin has specified which CLI command to execute. As parameters to the CLI command it is important that at least the following is sent:
- The type of object selected
- The id of the selected object

This will make it possible for the context menu item provider to execute its logic on the selected object.

All this is a bit similar to the current "mixer" functionality available in SlimServer 6.5. The main difference being that the current "mixer" API is a bit less generic. The main problem with the current "mixer" API is that:
- A plugin can only provide a single mixer
- The plugin doesn't get any good information from where the mixer was launched, it has to know the SlimServer internals to retrieve which object that was selected when the mixer was launched.

Let me know I you like all this to be a discussion in the "Developers" forum instead and I'll start a thread for it.

The Controller really needs this. I would like to be able to select a track in the playlist and move it up or down the order. Hold center button down for say 2 seconds to pop up a menu would seem to me like the obvious and only way to achieve this. However, i'm not expert anymore, but i can see this would probably take quite a serious and fundamental reworking of the code behind the UI. 

I'd like to have this implemented as according to forum threads, this is a
prerequisite to have support for rating in Duet (through plugin)

I think the best way to add additional controls and metadata about songs and stations is by extending the trackinfo screen, which is already available without any special new button handling.

I think andy has been thinking about the cleanest way to do this.  Andy?

(In reply to comment #7)
> I think the best way to add additional controls and metadata about songs and
> stations is by extending the trackinfo screen, which is already available
> without any special new button handling.
> 
> I think andy has been thinking about the cleanest way to do this.  Andy?
> 

Please remember that mixers and other functions should be possible to launch also from albums, artists and years in the browse menus. Extending the trackinfo screen only solves the problem in the Now Playing screen, the possibility to launch stuff from the browse menus won't be solved satisfactory by just extending trackinfo.

However, bug 6619 can be solved satisfactory by just extending the trackinfo screen.

We already have an shortcut for mixes by pressing and holding the PLAY button on the thing you want to create a mix for.

Well, you _could_ add mixers to the trackinfo by letting the user descend down to the song and then give them the choice to "Create mix with album <albumname>" and "Create mix with artist <artistname>".

It does mean that the user would need to descend down to a specific song, but at least it would be visibly simply by navigating down.

In sample 2 above, the items shown really do belong as new choices in the trackinfo screen.  I don't see why we'd need to create two different menus that contain metadata and actions for a song.

In sample 1 above, these already have reasonable interfaces:

- Play artist - Press the PLAY button
- Add artist - Press the ADD button
- View albums - Press the GO button
- View songs - Scroll to All Songs and press the GO button
- Create MusicIP mix - Press and hold the PLAY button

Which leaves:

- Remove arist from playlist - I'd prefer to see this in the Playlist menu, probably as an additional trackinfo item "Remove <artistname> from playlist"

- Rate artist - Similarly "Rate artist" would be just fine next to "Rate song" in trackinfo

- View statistics - I'm not sure what this contains.  Can you elaborate?

(In reply to comment #9)
> We already have an shortcut for mixes by pressing and holding the PLAY button
> on the thing you want to create a mix for.

Have this been added recently ? 
(play.hold action is not available on the Controller interface in 7.0 as far as I know)

If mixers provided by third party plugins now are available on the Controller interface, it is basically almost the same thing as the context menu described in this enhancement request, just a bit less generic if it has been implemented in the same way as the mixer API on the IR-remote and web interfaces.

The idea with this enhancement request is to avoid cryptical remote commands like "holding play" which is hard to remember for the user and instead show a menu to the users with available commands relevant for the selected item. Pretty much in the same way as the right click menu in the Windows Explorer works.


(In reply to comment #9)
> - View statistics - I'm not sure what this contains.  Can you elaborate?
> 

I had a link to the TrackStat plugin in my mind, but the idea is that it should be possible for a plugin to add custom items in the context menu.

From my point of view the purpose of a general context menu would be to allow for funcionality to be accessable without having to remember things like press&hold and the other crypticly accessed features that you "have to know" and remember.  Most functionality that already exists in SC it effectively not available to most users because of the old-style hot-key memory-based interface.  It is a large barrier to entry currently.  Ideally, every action that is valide from a particular place would be in the context menu.

Following Doug's comments, I think a context menu should be thought of not simply in terms of
 - the track that's playing
 - the item that's selected
but also other concerns like
 - the player that's being controlled (PowerCenter/BottleRocket, IR Blaster, or PowerSwitch might offer something like sending a power command to the amp, in case it didn't turn on as expected)
 - the state of the player (OtherPlayers might offer an easy "Unsync" option; SettingsManager might offer an easy way to load a saved settings group ["Load Peter's settings", "Load Party settings", etc.])
 - the state of the system (OtherPlayers might offer a sync option only if there are other players currently using SC7; SaverSwitcher would offer to switch screensavers if the off, idle, or playing saver were running)

Erland & I have traded messages elsewhere about some code I put together for IR remotes & VFD-equipped players. That code allows plugins to register with the context menu software so that when a user requests a contextual menu (with IR/VFD, this means sending a particular $button.hold IR command), the plugin can decide if it has any contextual option to offer. If so, it indicates this to the context menu software and its option is displayed in the UI. If not, then there's no hint of that plugin in the contextual menu that's displayed. The context menu core tracks usage stats and arranges the context menu first by frequency of use, and then alphabetically. There's no need for the user to drill-down to Now Playing, and the system "learns" what options the user cares most about, ultimately reducing he amount of menu navigation that's required.

I haven't looked into Jive support yet, but it should be a relatively simple matter to add a CLI to display the top-level context menu. The main thing is needing a button dedicated to jumping to the context menu.

Very keen to see this resolved, pursuant to getting valuable ability to rate tracks.

I know that it would be a radical departure from existing functionality but I've always thought that the "+" key would make a pretty good context menu...  "+" for "additional functionality".  The point, again in my opinion, is to make it user-simple/obvious so a dedicated physical button would be significantly better than some sort of "press and hold" scenario.  If the current favorites functionality is in the context menu then it would only be an extra button click or three to accomplish the same thing.  How often are people adding things to favorites now?  Would the couple of extra clicks required be significant?  I don't use the favorites functionality, myself, so I can't properly guage that.

Well, "+" is for playlist management, not Favorites. I think "+" has always been a little weird, especially "hold '+' to remove an item", but I don't know if that's the best choice.

I've been experimenting with arrow_right.hold mapped as the context menu key -- like "right click" on a desktop computer. So far it seems to work pretty well. A bonus of using arrow_right.hold is that that key is on all remote controls, and clearly labeled. My initial ContextMenu code includes a bunch of button mappings -- Browse, Favorites, Brightness, etc. A couple of my Squeezeboxes are in rooms with A/V systems, and I use a really basic universal remote control for them. Sometimes I cannot recall, for instance, which button is Size. It would be nice if the context menu access button were one that's clear on any old JVC DVD remote, universal remote, etc.

If any of you haven't already seen it, there's a thread in the developers' forum on the ContextMenu plugin I've developed and released:
http://forums.slimdevices.com/showthread.php?t=47886

Currently it only has a VFD/IR interface, and requires users to tweak their button mapping files. I think Erland had a great suggestion about Jive/SqueezePlay:

1) There would be a concept of "context menu providers".
2) SqueezeCenter would have an API to register a context menu provider.
3) SqueezePlay/Jive would map a button (center.hold?) to ask SqueezeCenter to invoke the context menu provider.

A plugin like ContextMenu would register as the context menu provider. Plugins like TrackStat would register options with ContextMenu. When the user presses the context menu button on the Controller, SC7 executes a ContextMenu function (since ContextMenu had registered as the context menu provider), which in turn checks with plugins like TrackStat to see which registered context menu options should be displayed. The user could then choose the TrackStat context option and interact with menus controlled by TrackStat.

I think we should also modify the SC7 default IR & Front Panel maps so there would be a consistent way to invoke the context menu provider from Squuezebox Classics and Transporters, too.

As of SC change 20657, SC plugins can register two keys 'cliBase' and 'contextToken', to the hashref structure pushed to addImporter. cliBase is the base command for an item

as an example, this is what's now done in the MusicIP plugin:

              Slim::Music::Import->addImporter($class, {
                        'mixer'     => \&mixerFunction,
                        'mixerlink' => \&mixerlink,
                        'use'       => $prefs->get('musicip'),
                        'cliBase'   => {
                                        player => 0,
                                        cmd    => ['musicip', 'mix'],
                                        params => {
                                                menu => '1',
                                        },
                                        itemsParams => 'params',
                        },
                        'contextToken' => 'MUSICMAGIC_MIX',
                });

Behavior on the controller should be as follows:

0 mixers, play-hold does nothing
1 mixer, play-hold invokes the single mixer with the cli command described in cliBase + whatever item (artist, album, track, genre, etc.) as a parameter.
2+ mixers, play-hold gives the user an interim "context menu" window to allow them to select from their n mixers. I'll attach a screenshot showing that.

play-hold on an 'unmixable' item doesn't push the current window off screen, instead displaying a showBriefly poup saying that PLUGIN is not available for this item.

There will probably be some tweaks to allow non-mixers to also be in this menu, but to some extent we're running into some redundancies with bug 6930 and bug 6619.

Created attachment 3420 [details]
screenshot of controller item context menu

note: I did a very rudimentary hack to a couple of Erland's plugins to make them show up on this menu...I didn't go as far as to make them functional.

I haven't heard any feedback on this, but I do believe the base support for this to be complete.

Have the base fuctions been moved into the context menu or is this only for plug-ins?  I don't tend to use a lot of plugins so I might not be able to see much yet.  I do use MusicIP so I'll take a look at that as soon as I get my home internet back and can update (a long and involved comcast cable issue I won't bore you with here).

Doug- I'm confused, what base functions are you referring to?

I would expect the context menu to be a visual way of picking and doing pretty much anything that is correct for the current context.  Certainly things like add/remove from favorites or playlists, etc.  What are the total number of actions that can be performed on a song object, an album object, etc.  Some, like play and pause, may not be included from a clutter point of view as they have obvious dedicated buttons (the plus key is NOT obvious to a new user) but that would be very rare, I would think.  At least that is what I thought this was all about, anyway.

okay sorry, my mistake. Re-reading the long comments in this bug, what I've done thus far is not feature complete for what's been requested.

What's available now is a means for SC plugins to register a cli command to be issued against "mixable" objects (I use that term loosely, as there's no reason this needs to be limited to "mixers").

I guess I'll just reopen this for now. Not sure of a time frame on the full set of what's requested.

I certainly may be scope creeping this one unintentionally.  I was directed to this one after some earlier discussion - perhaps incorrectly?  Although rereading the first paragraph of this enhancement agian I still read it as what was intended/requested.  Certainly plug-in support is step one of a larger project if that makes the most sense.

This is too bigger task for 7.1. Dean we need to decide if and how we will implement this functionality. Can you please give this some thought.

I've been thinking about this and it seems to me that this is really an extension of the trackinfo menus/screens which provide metadata and extended browsing for songs and radio stations, but extended to work with artists, albums, genres, and possibly more.  Let's call this the "iteminfo" menu (and not just the trackinfo menu).

I propose two things:

1.  Extending the trackinfo framework that andy has recently revamped to accomodate building menus for artists, albums, genres, etc.

2. Standardize on discoverable user interfaces that make it easy for folks to find this menu.  

Some thoughts on #2...

We already have iteminfo readily available for songs and radio stations.  On the classic player UI, Controller UI and Web UI, you select the item (right arrow, center button, click on the title) when displaying the song/track/station name to see the iteminfo menu.   Done.

A easy-to-discover approach to adding the iteminfo menu to, say, an artist (use Madonna for example) would be to add to the end of the artist's list of albums an item titled

"Madonna Details" or
"Madonna Info"

That item, when selected, would take you to the iteminfo menu for Madonna.

I also hear that folks want a quick way to get to that menu and a long-press-and-hold on Madonna's name could be a shortcut to Madonna's iteminfo menu.

I'd like Andy and Brian's feedback on this.

Unfortunately, I think we won't have time to get this really solid for 7.2 (sorry for punting again, it's been busy around here).

Maybe I'm not reading this correctly, but I guess what I'm looking for here is to be able to see "ALL" of the action items of a particualar thing by performing some quick key press (mouse click?).  The equivalent of the Windows right-click shows that you can cut, copy, paste, and 10 other things that vary from place to place.  This sounds like it might be mixing information, sub-items, and actions together?  That could make things rather long and cumbersome, wouldn't it?

For instance, from an album I'd like to activate the context menu "Some Way" and then see items for "Play Album", "Create MusicIP Mix", "Album Information", "Add to Playlist", "Add to Favorites", "Play Next", etc.  Anything that does antyhing from this "place" should be in the list.  

You could build the list up from the actions from all of the buttons if they, the actions, all had names somewhere.  

A plug-in should be able to add its actions to the list as well (as noted by the Music IP entry).  

Might be nice to put the key shortcut (if there is one?) after the name as well to let people know about them easily.  Example: "Create MusicIP Mix (Hold-Play)" would be a good entry.

As for the "Some Way":  Could it be user-mappable?  Reason: I'd probably prefer it on the "Plus" key and move the "Add to Playlist" to the "Hold-Plus" function.  The reason is that press and hold is subject to stuttering - You meant to hold it but didn't quite get it right and instead it performs an unintented action.  Much safer (and obvious) to have it on just the press of a button.

My intention is to provide as much feedback for consideration as possible.  I think that I'm sticking to the original intent of the request.  I'm also not too sure what the proper protocol is for this sort of thing (very new to this open source design world) so let me know if I shouldn't be adding this in here, etc. (or if you just get tired of me repeating obvious things...  :) )

(In reply to comment #27)
> Maybe I'm not reading this correctly, but I guess what I'm looking for here is
> to be able to see "ALL" of the action items of a particualar thing by
> performing some quick key press (mouse click?).  The equivalent of the Windows
> right-click shows that you can cut, copy, paste, and 10 other things that vary
> from place to place.  This sounds like it might be mixing information,
> sub-items, and actions together?  That could make things rather long and
> cumbersome, wouldn't it?

I think it's just a matter of deciding what should be in that sub menu. There is no reason the sub menu can be hierarchical into several levels, so actions/functions could be shown in the first level with a "Show details" element which you can enter to show more information.
IMHO, it is very important that the top level of the context menu isn't filled with just information items because that will make the "actions/functions" too far away.

To me it sounds like Deans suggestion should work, but I think it is really important to have have this easily accessible with a shortcut button like "a long hold" in the Controller and Player interface. In the web interface I think the preferred way to access this would be an icon which showed a drop down menu.

It would be really great if we could implement this so custom plugin specific browse menus with custom objects could use the same menu framework while the SqueezeCenter core just adds custom objects for the standard SqueezeCenter objects like artists, albums, tracks, genres, playlists, years and maybe some related to radio stations.

Dean, Andy, Brian, when deciding which way to go I would also suggest that you have a look at Peter's ContextMenu plugin mentioned in comment #16.

I'm glad there is an existing plugin trying to solve this problem, but for core we will use the same system already in place for TrackInfo.  ItemInfo is as good a name as any.

(In reply to comment #29)
> I'm glad there is an existing plugin trying to solve this problem, but for core
> we will use the same system already in place for TrackInfo.  ItemInfo is as
> good a name as any.> 

I was just thinking that it might give you some ideas what functionality is needed, I'm sure the current TrackInfo framework can (and should) be extended to support the neccesary functionality so I'm not saying you should use the plugin code just get some ideas from it. One thing to have in mind is that the current TrackInfo menu framework is very information focused today while I think this context menu should be more focused on commands/actions. It's not a big difference but looking at the referred thread in comment #16 might give you some ideas.

It's important that the context menus can be used for things like:
- Choosing sorting order of the menu you are standing in
- Access third party plugin information in the context of the currently selected item
- View more information about the selected item
- Access to commands that are hard to find today, such as "Delete from playlist", "Launching mixers", "Insert into playlist after currently played item".

There has to be some kind of callback so a specific menu item can be shown/hidden based on which item is selected. One example where this is the case is for MusicIP mixes where not all tracks/albums are mixable.

One other aspect is that the callback shouldn't have to know from which menu it was called, it should be enough if it gets the currently selected object as parameter. I think this already is the case in the TrackInfo menu but I'm not completely sure. However, it is NOT the case in the current mixer API which is very dependent on from where it is called so it is almost impossible to launch from third party plugin menus.

But I'm not going to repeat myself over again, there is enough information already in the comments to this enhancement request and the referred threads, so I'm sure you guys are going to get it right when you start to implement this.

Dean & Andy, I have some questions about your plan:

Q1) Will iteminfo be available for every item in the Player and Controller UIs?
Your examples only cite music sources & library entities. I could see uses for
contextmenu/iteminfo options for other object types -- for instance, I might
want an option from the Settings menu item to use SettingsManager to apply a
set of saved player configs. Or from Random Mix I might want to invoke a plugin
that applies a set of named Random Mix settings ("Jazz and Classical albums",
"Pop/Rock/Hip Hop songs", etc.). 

Also, from any menu location -- especially on the Player and Controller UIs --
I'd want a chance to act on the currently playing track (e.g., rate the track with TrackStat, note info about the track with PlayLog).

Q2) Will the appearance of individual iteminfo choices be dynamic? For
instance, a lyrics plugin might want to offer a way to browse lyrics for songs
in a particular genre, but only if it had lyrics. E.G. it would show an option
for Music Library -> Genre -> Gregorian Chants but not for Music Library ->
Genre -> Instrumentals.

If you're too busy to wade through my ContextMenu discussion thread, here are
its answers to those questions.

A1) Yes. ContextMenu is always available.

A2) Yes. Before displaying a list of context options, ContextMenu checks to
verify that the option is valid, and gives the plugin providing the option the
ability to set the label to be shown. There is some small overhead to this, but
it keeps the list tight & clean, like a desktop OS' right-click menu.

Furthermore, in an effort to make the context menus quicker & easier to use,  ContextMenu currently allows users to choose between alphabetical sorting of options (defaults to the last-chosen option if it's still available) and sorting by frequency of use (so the most likely options are at the top). The ability to completely re-arrange the order of display (via fixed "weight" values) is half done. Users can also choose to disable specific options to unclutter their interface. And ContextMenu is even accessible when a player is "off", for options like AllQuiet's "pause all players" feature.

I'm not trying to lobby for ContextMenu over your plan, just trying to learn
more about how your idea would address concerns and use cases I've identified
while developing my plugins.

Thanks.

Created attachment 3712 [details]
Patch for MusicIP plugin for 7.2/trunk branch

If MusicIP analysis is performed after a SqueezeCenter scan, SC will not know that the songs are mixable.  If file timestamps are updated after the analysis is complete (eg. using archive analysis within MusicIP without preserving timestamps option ticked), the next SC scan for new/changed files will determine the mixable status.  Alternatively, a full rescan will always determine the mixable status of all songs.

Another idea I had is for a new/changed rescan to check MusicIP mixable status for all songs that were previously not mixable, even if they have not changed in SC.


Dan Sully suggested an alternative/additional scanning mechanism:

"I think the best way to go about this is still pulling down the
mmm-data / extended, and then scanning through that, turning it into a hash of
filenames to MiP active files. This could even be persistent via DB_File.

That way, even for a wipe, if the user is not using MiP as their primary
database (setting option?), it can just be an O(1) lookup, and there should be
a callback available for the main music folder importer to call and set the
setSongMixable()."

Sorry, ignore the attachment and last comment I added here - wrong bug report.  bugzilla now moves to the next bug in my list after making a change, which is so unhelpful.

I can't delete the attachment or comment, so it's stuck here.

Any update on this, especially Dean's proposals in comment #26 ? 

Just between the two of us, Erland and I now have 8 plugins using my ContextMenu plugin for conetxtual menus in the old-school "Player UI" (9 if you count the fact that ContextMenu itself offers context menu options). I've been thinking more lately about diving in to Lua and adding SqueezePlay support for ContextMenu, but it would be much better if something like ItemInfo were a core part of SqueezeCenter/SqueezePlay rather than a 3rd party plugin.

Reset priority before triage.

due to the length of this bug I'm inclined to mark as resolved (since we now do have context menus) and ask that the extended discussion make it's way into new bugs. But for now I'm kicking the priority down several notches.

this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.

We're delivering CMs in 7.4. There is obvious room for improvement, but much of that is covered by other bugs and this bug is no longer the forum for it. Closing.