Bug 9914 - SC-delievered menus should be able to send callbacks that launch native SP applets
: SC-delievered menus should be able to send callbacks that launch native SP ap...
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: Browser
: unspecified
: PC Other
: -- normal with 1 vote (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks: 5437
  Show dependency treegraph
 
Reported: 2008-11-06 08:14 UTC by Ben Klaas
Modified: 2011-11-06 23:25 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Klaas 2008-11-06 08:14:09 UTC
currently callbacks to squeezeplay menu items delivered from SC are only configured for sending back cli commands to SC. Would be nice to have a means to have the item call a native applet method (e.g., load NetTest against a particular player)

see campfire chat captured in bug#5437c24
Comment 1 James Richardson 2008-12-19 08:03:57 UTC
Changing target to next release
Comment 2 Richard Titmuss 2009-07-27 03:33:11 UTC
We'll probably need this for photos
Comment 3 Ben Klaas 2009-08-03 06:49:38 UTC
Tom, I'm assigning this to you but we might work together on this.

Richard thinks a fix might be necessary for some of our new "apps"
Comment 4 Erland Isaksson 2009-08-18 21:38:31 UTC
I have a problem that might be related to this.

I'd like to be able to open a browse menu for a specific artist or album from my own applet. 

At the moment it's easy to issue the browse JSON command to the server but the problem is that when I get back the result I haven't found any way to pass it to the SlimBrowserApplet so it can open the window and show the menu.
Comment 5 Wadzinski Tom 2009-08-24 19:34:47 UTC
Richard had wanted a generic mechanism for calling into SP applet methods from 
SC. I didn't do that for photo applets. Pushing this to P2 as we could still 
use it for delivering things like Info Browser as an App (you can swtill get to 
it by going to Customize home menu)
Comment 6 Ben Klaas 2009-08-26 07:53:34 UTC
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.
Comment 7 Chris Owens 2009-10-21 09:49:42 UTC
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
Comment 8 Pat Ransil 2009-10-23 05:11:23 UTC
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Comment 9 Pat Ransil 2009-10-23 05:17:28 UTC
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Comment 10 Chris Owens 2010-03-08 11:33:07 UTC
Moving lower-priority bugs to next target
Comment 11 Chris Owens 2010-05-06 15:38:02 UTC
Tom is no longer available to us
Comment 12 Alan Young 2011-11-06 23:25:14 UTC
Unassigned bugs cannot have a priority.