[mythtv] Development task list:

[Ed W]

>>>As for incorporating the plug-ins... I'd rather see a plugin API 2.0
>>>with calls added to make plug-ins embeddable, focus switchable, etc.
>>>      
>>>
>>I just would like to see the user interfaces for the various plugins 
>>more  
>>integrated, really.  Whether that's through absorbing the plugins or 
>>another  
>>method, I don't really know yet. =)
>>    
>>
>
>At the very least I think any media-playing plugins should be integrated 
>(i.e., mythmusic, mythvideo, possibly something akin to mythstream or 
>mythradio, etc).  It would probably simplify things to have all media 
>meta-information and playback handled in a consistent manner.
>  
>

Whilst I kind of agree, I would suggest that the best way to achieve 
this is to break it *down* more, not integrate more.

Consider that the re-write is a fairly major undertaking anyway.  I 
might structure it that I would look at the top level of the major 
objects and split the code out at that level and call it an interface.

So consider that Myth toplevel becomes a simple framework that can show 
small sets of screens and handle state.  Then each screen that wants to 
appear registers input and output methods and gets to share the state 
info so that it can pass on messages.

So TV becomes an object, it can be tuned in to a channel and then after 
that it broadcasts video to the registered listeners.  However, the 
framework has switched over to the EPG view which decides to show the 
current streaming video in a small window top right (or not).  Then the 
EPG based on feedback from the user retunes the TV object to some other 
channel and the resulting streaming video eventually appears in the 
preview window in the EPG.  The user might then switch to the music 
player without killing the TV and have that as one of the visualisations...

The idea would be to have the "player" module become a lower level 
object and have the framework become a simpler higher level system which 
just shuffles around various "plugins" or screens, possibly raising 
events when it does so in order allow us to trigger external events when 
things happen (dim the lights when the video comes on?).

Another goal would be to tackle what appear to be a number of race 
conditions and other subtle bugs which really seem to occur because the 
current system is quite tightly integrated.  ie you can change channel 
and have something lock up else where because the channel changed a bit 
too fast which meant the audio wasn't quite ready, etc.  Perhaps we can 
have more of an interface between sections, reduce the tight coupling, 
make it easier to debug, but still keep decent performance?


Actually, it occurs to me suddenly that what we really want is to build 
a *single* video & audio playing application which is remote 
controllable, but has NO gui.  The entire rest of myth then becomes just 
one possible GUI.  This makes it much easier to program up a music 
interface (or even three interfaces if there is some competition) 
because there should be NO music playing code in the user interface.  
Instead we can just let the GUI designers get on putting buttons on the 
screen and they should then be calling methods no lower than: 
player->pause(); player->addtracktoplaylist(blah); player()->play();

We can split development effort then between building a decent player 
object and building a GUI wrapper around it.  It ought to be easy to 
have a multitude of different GUIs

Consider (not literally) rebuilding myth as a GUI around xine.  I mean 
this only in the sense that if you did this you would take the media 
playback stuff for granted and build the UI at a much higher level.  
Today there is a lot of integration of the GUI code and the backend 
code.  So perhaps it makes more sense to build a better "standalone" 
media player and have the frontend loose all it's tight integration and 
instead become a controller. 

Notice that this is already how Xine is built.  They make the player 
application seperate from the GUI - and in fact there are quite a few 
GUIs for xine...  Perhaps we can learn something from this and do 
something similar with Myth?

This gets us back to perhaps having a three piece system: backend 
creating content, media player displaying it, controller making stuff happen

Perhaps such an architecture would also make it really easy to have the 
controller on a palm pilot or a web page...

Anyone biting?

Ed W