This will take some thought.
Basically, it would actually mean IMPLEMENTING the Photo mediatype, instead of just having it go to the details page and have a screenhandler remove the play button (COP OUT!).
This would be pushed to a Photo Plugin, which would route to the Photo Screen Saver.
We would need to modify the Orbiter Plugin a bit to pass back the requested pictures that are fed from the playlist on the media plugin.
The _COOL_ thing here is just how much we can leverage everything in the system:
The MD becomes the main viewer, but keep in mind that while viewing a piece of media, the Orbiter is also displaying a remote control, right?
New Photo Remote control, with a nice big objPhoto designobj, that gets updated with Update Object Image from the Photo Player, and a set of simple controls to traverse the playlist.
As for handling multiple types of media, this will take some restructuring of Media Plugin to handle playlists of composite types (in short, STL SUCKS! We have to make sure to type-cast and convert-cast our media stream types back and forth between the media plugin and the appropriate media player plugin, this is just one example why this part's not gonna be easy...)
Yeah it is cool that we can leverage so much existing functionality to build this off.
- Guess as with other media types if you are remotely controlling the 'playback' of some PHOTO media on an MD from another Orbiter then you should see an on screen remote locally on that Orbiter. However if you are directly controlling the PHOTO media playing on your local MD then I guess the media would play full screen?... with control from say your IR remote? Not sure about that part I have to say... needs some thought. But I feel that you should be able to 'play' the PHOTO media without seeing any on screen controls.
- Multiple mixed media types in a single playlist can come later in my view. Getting the basic PHOTO media playback working is in my view more important in the initial implementation.
Thanks for the input Thom :-)
Happy New year!