[mythtv] Better Integration of plugins

Paul Volkaerts paul.volkaerts at lineone.net
Fri Feb 25 00:24:21 UTC 2005

> Heh, cool - the UI part of this is what mythui is partially supposed to
> accomplish.  I had intended to convert over the OSD code so it
> uses the same
> base classes/etc for drawing as everything else will.  This way,
> anything can
> draw on the OSD (or anywhere else) without being written
> specially for it,
> etc.  I'm not really sure if there's benefit to a separate worker
> function
> that way, as mythui already (mostly, at least) has the functionality of a
> screen separated from the actual drawing.  Whaddya think?

A common set of clases to handle drawing on top of TV or on QT is definately
a good idea.

But how to handle multiple plugins all wanting to access the display is the
problem as I see it; and I can think of two options:

(1)Do what most OS'es do, which is have a kernel of functions that are
re-entrant and can be called by any plugin.  When awoken by some user input,
the plugin would grab the keyboard, open a window, and start drawing. This
is fine in an OS where the user decides which application has focus, but
harder in a TV environment. I "think" this is what you are advocating, with
mythui providing this set of functions.  Is that right?  Thats quite a task
I would imagine, but I think is the best solution.

(2)Or, you have one thread that owns the display and other threads sends
requests to display information. This means plugins must be able to run as a
worker function; but it gets round the control issues in (1). This is
definately how my mods work; but I chose this method based on it being
simple and not the best way.

So to me, option 1 would be excellent but appears to be masses of work. It
would give a level of flexibility that is essential in a workstation, but
I'm not sure is a as important in a TV set-top box.   Option 2 is inferior
in terms of flexibility but is much simpler.


More information about the mythtv-dev mailing list