> 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. Paul _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
