Bugzilla – Bug 17137
trigger raising of CMs when isContextMenu flag is in the action
Last modified: 2011-04-20 01:57:20 UTC
in Eastman we need to make a similar change to the SP change r9337. This change tells the client to make the next window a CM when the isContextMenu flag is attached to the item action (item->actionName->isContextMenu), or in the window block of the base's action (base->actionName->window->isContextMenu). see also bug 16697, which when fixed will also allow isContextMenu flag to be set on base->actionName->isContextMenu as well as base->actionName->window->isContexMenu actionName = the name of the action, e.g. 'go', 'do', or potentially an arbitrary action name e.g. 'playlistControl' captured campfire discussion: Alan Y. In SP, I made a change, so that a 'go' action which also had the isContextMenu flag set would open a context menu. Let me dig it out Ben K. I think that's r9337 Alan Y. Looking at the code now, I am confused ... Ben K. local isContextMenu = _safeDeref(item, 'actions', actionName, 'params', 'isContextMenu') or _safeDeref(chunk, 'base', 'actions', actionName, 'window', 'isContextMenu') Ben K. so that's the isContextMenu flag in SlimBrowser. Comes from either the item's action params or the base action's window params (yuck, I know, I opened a bug against that mess) Alan Y. Ah, now I remember. The actual name of the action is not 'go'. It is something arbitrary (actually 'playcontrol'). But it should still get a CM Ben K. it appears your r9337 is a change to allow a CM to raise if that flag is true Alan Y. yeah, even if it not a 'more' action Ben K. that sounds right. So now as long as isContextMenu is true, CM gets raised and judging by the paste above, that would work with arbitrary action names Alan Y. Any action, that was not handled by one of the earlier clauses, can raise a CM if they have that flag set,. Ben K. yes, I agree so I guess the point is that the same logic needs to be applied to Eastman Alan Y. Yeah, that was the point. The server-side code is using a goAction mapping, so the actual action name is not 'go' This is not really for onebrowser, BTY. It is for defeat-touch-to-play. s/BTY/BTW/ Ben K. okay, that's fair. thanks for digging those faint memories back up :) I think it's a reasonable change outside of the defeat-touch-to-play objective Alan Y. sure It also depends on the goAction mapping being in place - I think Michael did eventually do that. Ben K. Okay. I'm going to open a bug and capture most of this discussion. I'd guess it should be a simple change in Eastman to check for isContextMenu though
is there an easy way to test the new behaviour?
cc:ing Alan the principal way to test is with Alan's optional defeat-touch-to-play code in onebrowser. I've not played with it, but when used playable items send an isContextMenu flag on an action called playlistControl
Set the server preference 'defeatDestructiveTouchToPlay' (or the relevant player player-pref of the same name) to 1 (other values are available but 1 is quickest to test with). All touch-to-play actions should now bring up a CM.
Is defeatDestructiveTouchToPlay going to be an official feature in 7.6? Right now it can only be enabled through direct pref editing, but none of the UIs, right? Another issue I'm seeing: should it respect the "play other tracks" preference? AFAICT it doesn't. Playing a track from the popup would only play that single track.
== Auto-comment from SVN commit #8366 to the player repo by mherger == == http://svn.slimdevices.com/player?view=revision&revision=8366 == Bug: 17137 Description: add support for isContextMenu flag.
don't create a new popup if the isContextMenu flag is returned for a context menu item (eg. More Info)
== Auto-comment from SVN commit #8397 to the player repo by mherger == == http://svn.slimdevices.com/player?view=revision&revision=8397 == Fixed Bug: 17137 Description: don't open another context menu when it's already shown (eg. "More Info" on a trackinfo CM)