[mythtv] Better Integration of plugins

[Joseph A. Caputo]

On Friday 25 February 2005 10:17, Paul Volkaerts wrote:
> > This is how mythui works (kinda).  Check out the drawTimeout()
> > function in
> > mythmainwindow.cpp in libs/libmythui/.  No actual drawing happens
> > outside of
> > that function (but the UI objects can be updated, etc, outside of 
> > it). 
> > Actually, look at the rest of the architecture there, it'd be
> > easier than me
> > explaining, and it's all fairly simple.
> 
> Ok I get it -- so it would still be a single-threaded drawing process, 
> and 
> if you wanted to have a plugin window on top of the TV, then based on 
> some 
> event/keypress you would create the plugins QWidget in the same thread 
> so 
> using the same QT event loop.
> 
> This certainly looks the right way to do it but it does seem a hell of 
> a lot 
> of work. In order to get plugins to draw on-screen as per my example 
> you 
> have to
> 
> (1) Get MythUI to have an OSD versus QT abstration layer and implement 
> the 
> OSD paint functions. Is that in hand?
> 
> (2) Change the plugins so that they have a full-screen mode and a 
> popup 
> mode. I guess thats required whichever way you do this.
> 
> (3) You still need a popup menu that integrates all plugins so the 
> user can 
> choose "music" without exiting TV. I think my menu was as good as any 
> at 
> this; and am happy to either check it in or put it in storage until 
> its 
> needed.
> 
> (4) How would you see a plugin being able to draw to the screen 
> without user 
> interaction, for example like the Caller Display.  Would you see the 
> plugins 
> QWidget having to exist all the time but sit quietly in the 
> background? 
> 
> Would be good to understand what is in/out of scope for what you are 
> coding; 
> then I can figure out how I can help.


I have one question about all of this:  this seems to be moving in the 
direction of making a large portion of the Myth interface (at least 
optionally) OSD-based; i.e., the ability to navigate & use most Myth 
functions without leaving full-screen TV-mode playback.  This is fine, 
and I agree that it would be really cool to have for a certain subset 
of Myth/plugin functions.  Some things, however, are too "busy" to work 
really well as a video overlay.  What about (and I know I've suggested 
this before, but now it seems like something's on the verge of being 
implemented) giving *all* screens the option to have a 'hole' container 
that would display a preview-sized window of the currently playing 
video, a la the EPG in LiveTV mode?  This is how Win MCE does it, IIRC 
(not that that should be our benchmark).  This also would have the 
advantage of working well on certain frontend systems that have problems 
doing the OSD overlay.

Ideally, I think a combination of both types of interfaces where 
appropriate would be the best approach.

Just my $0.02.

-JAC