Dnia 2009-07-02, czw o godzinie 13:02 -0700, Kevin Fox pisze: > There has been a lot of discussion on how a PVR (backend) should work. > If we're just doing PVR plugins that interface to PVR Backends, then > we > don't need to discuss that part at all. Its out of scope of Moovida. > All > we need is coming up with the generic UI components needed by the > various plugins, and let the plugins or the backends specify > recording/user interaction behavior. For example, the EPG, Dialogs > that > the PVR might want to pop up asking questions, etc. The plugin decides > when and if to pop up a dialog related to scheduling questions.
Yeah but that does not IMO undermine the need to talk about UX. A lot of the experience may be done in the plugin itself, regardless of current backend's standard behavior. > > Didn't we agree that we > > should have it as flexible as possible to support multiple - > different > > - > > backends? > > The two of us have. I'm wanting to make sure Fluendo is on board with > the ideas we've had. In particular, the comment in the other thread > about having Movies/TV Shows/Pictures/Music not be local but a meta > location. I don't think Fluendo is the decision making party here. We can always fork if they don't do what we tell them to ;) > > The only thing I wanted when arguing pros and cons of mythtv > > and dvbd is with which one should we start. > > Ah. ok. > > Since dvbd is not usable right now for me, and my time is somewhat > scarce, I'd probably only be able to help with the myth one. That > doesn't mean people can't be working on both (or a vdr one for that > matter). Yeah I can imagine. I think starting here is fine, forcing as much of our ideas (that are different from default - mythfrontends) as possible. So - again - IMO we need to define all our wishes regarding the experience, then cherrypick those we can do and prioritize them. Then we can define what UI features we need and start there. > > The only question is that: should we build a general, abstract 'TV' > > plugin that would then be subclassed to support different scenarios? > > That would surely require more work to design it with enough > > flexibility. > > Thats a good question. It could be also, do we create a superclass > that > all pvr plugins subclass, or do does Moovida provide a set of widgets > used to implement a TV plugin. Slightly different, but subclassing the > TV plugin kind of forces a UI and behavior a bit on the plugin, while > allowing the plugin to use UI elements or not based on its choice is > different. > > I'd vote for the latter. We provide a set of widgets, EPG, Player, etc > which the plugin can subclass to receive the hooks it needs to > function > properly. Or it can extend it to provide additional information. Say > the > enhanced EPG that mythweb uses to show recordings that are happening > by > changing the color/border of a cell in the EPG. Some PVRs might not be > able to access that info easily. I think we need both... Create widgets as generic as possible for our uses as well as a 'skeleton' plugin or maybe some things in moovida core that will then be inherited by backend-specific plugins. Moovida devs will probably need to say something here. > Does this sound reasonable? Yes, certainly. > If we can get a response on how the TV Shows/Movies/Music/Pictures > should work, maybe I can then come up with a writeup of: > > --- Generic --- > > 1) What Widgets from Moovida we'd need for any PVR plugin. As mentioned, I would start with a 'wishlist' for user experience > 2) What hooks/behaviors we would need from the Widgets (Example, > Player > allowing a dialog to come up in front) Modal popups are already there. > 3) For Widgets not currently in Moovida, UI we'd like to see (EPG, > full/now+later) Hmm why did you split 1) and 3)? > 4) How and where generic PVR menus should show up in Moovida I think we should start with the standard 'other computers' view, that will then, when we get source aggregation, fit in other views. > --- MythClient --- > > 5) What the UI specifically for a Myth Client plugin should look like > > Sound ok? Cool. -- Michał Sawicz <[email protected]>
