[mythtv] OSD timeout settings

[Lennart Sorensen]

On Wed, Jun 16, 2010 at 04:37:03PM -0400, Michael T. Dean wrote:
> My real preference is appropriate defaults so that no settings are  
> necessary.  With settings, users won't know which displays are affected  
> by which settings (and, for that matter, it's possible that the same  
> display in different contexts will be affected by different  
> settings/timeouts), so it's just confusing.  Or, users will have  
> different opinions about which displays should use which timeouts.  (Not  
> to mention that I have sent way too many posts to the lists telling  
> users what settings their looking for and where to find them--i.e. setup  
> is /way/ too confusing because long-time users can't even find the  
> settings they want.)
>
> Or, perhaps, something completely different...  For example, maybe any  
> user-initiated OSD is displayed for a long time, but  
> automatically-displayed OSDs are displayed for a short time.  On short  
> OSDs, users can extend the display (with the INFO button or whatever),  
> on long OSDs, users can dismiss (with ESCAPE, as always).

I would like info to dismiss it too.  So info toggles it on and off,
with the timeout being the automatic off.  Well at least info dismiss
anything info put up.  The OSD for channel changes and such I am not
sure why I would ever want to extend for any reason.

> IANAUIDE (I Am Not A User Interface Design Expert), so really, I'm  
> really not the right person to come up with a better approach.  Getting  
> a UI design expert to help would be ideal, but it seems most of them  
> gave up on MythTV years ago.  ;)
>
> That said, if we go back to the old approach, I can live with it--as  
> long as it's applied consistently and universally.
>
> Basically, I'd like to take the opportunity to rethink old behaviors and  
> improve.  Unfortunately, it seems that inertia may make major  
> improvements impossible.  I fully admit that I don't have a plan.  I  
> don't really care that much about this particular issue (other than  
> insisting that it's at least a complete implementation unlike what we  
> had before).  So, I'll leave it up to others.

-- 
Len Sorensen