[mythtv] OSD timeout settings

[Mark Kendall]

On 15 June 2010 23:21, David Engel <david at istwok.net> wrote:
> On Tue, Jun 15, 2010 at 01:32:41PM +1000, Jean-Yves Avenard wrote:
>> Following http://svn.mythtv.org/trac/changeset/25102
>>
>> Is the plan to have something equivalent with the new OSD theme, that
>> is the user can easily change the timeout settings and how long one
>> has to read text displayed on the screen.
>>
>> If it will require to fiddle with the theme XML to adjust how long you
>> have to read things , that's a big drawback usability-wise IMO.
>
> I agree completely.  I understand the desire, even need, for the
> themes to control all visual aspects such as fonts so things look
> right.  OSD timeouts don't affect the visual appearance of the themes
> and should be easily configurable without having to edit XML.
>
> FWIW, I'm also not thrilled with the change (unless I've misunderstood
> it) that removes the ability to independently choose the OSD theme.  I
> have no problem with a setting that defaults to using the OSD theme
> provided by the main theme, but why not let the user choose a
> different OSD theme if they want to?

For the record, following r25031 (and as subsequently noted in r25094)
I raised the issue of OSD timeouts on the irc dev channel and asked
whether they should default to hard coded values, be configurable via
the OSD settings or configured within the theme. From memory, everyone
who responded suggested the theme route and Michael's removal of those
(and other) settings was a response to that discussion.

That said I should point out that I'm largely agnostic about the 2
issues already raised (timeouts and theme choice). But I do think
there are broader issues.

With respect to the timeout settings, how many people would actually
notice and/or care if the default/fallback theme settings were 5
seconds in general and, say, 10 seconds for more verbose windows?
Indeed, how many themers would actually bother to change the defaults?
Furthermore, given that the themer has complete control of the
graphical presentation, text size, text font and to a lesser extent
the text actually presented, the timeouts are just another element of
that presentation. Sensible defaults for the timeouts are, I would
suggest, less likely to generate debate than something like font sizes
(which can't actually be changed without breaking the theme anyway).

As far as the OSD theme is concerned, there is, I think, currently no
technical reason why the OSD theme cannot be different from the main
UI theme. That is, however, a consequence of the current code
limitations around inheritance and the image cache - both issues that
I hope will be addressed soon. Following that the OSD will, by and
large, explicitly inherit from the main UI theme and significantly
simplify themeing of the OSD. But why would you want a different look
and feel for the OSD and the main UI? If I'm at cross purposes to the
general view, then it's time for me to move on. That was, after all, a
significant objective of the 'project' I've spent the last 6 months
working on.

But if you look forward and anticipate a far richer UI experience from
MythTV, it is a natural consequence that both issues fall by the
wayside...

libmythui already offers the themer several choices to animate widgets
- changing the colour/alpha, moving, scrolling text, fading in/out
(etc?). Fading out the OSD windows is nothing more than a special case
(i.e. a largely hard coded effect) and, as it stands, all these
effects are themed and operate independently. But (again!) if we
develop a more generic approach to animation within the theme, as
suggested on irc, then the themer has the opportunity for a myriad of
effects. Are we going to legislate for every possible personal
preference with respect to how those animations will work? I very much
doubt it.

and when (not if) we get to the stage that the OSD and UI themes are
fully merged, then clearly the theme choice is moot. If you take the
first leap of faith that a new 'video/media' widget is forthcoming for
libmythui (i.e. a more generic video preview window), you will
appreciate that the UI library (libmythui) is poking at the bounds of
the TV library (libmythtv) and that the TV library is already more
than poking at the bounds of the UI library with the new OSD code. The
boundary is already blurred and it is a natural progression that at
some point the two will somehow integrate - the debate is then around
how and when that happens and, depending on the timescales involved,
which APIs to support for video acceleration and UI presentation.

Anyone who has followed my view on future development will know that
the last comment is loaded but, regardless, I would ask anyone
involved in MythTV development to try and look beyond what is
currently available and imagine something better. If the focus is on
whether 5 seconds is better than 6, I'll probably just cry myself to
sleep and get a more fulfilling job in the morning.

regards

Mark