
mark.kendall at gmail
Jun 15, 2010, 11:04 AM
Post #6 of 23
(2902 views)
Permalink
|
On 15 June 2010 23:21, David Engel <david [at] istwok> 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 _______________________________________________ mythtv-dev mailing list mythtv-dev [at] mythtv http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|