[mythtv] RFE: conditional UI settings presentation

Nathan Ziarek htpc at ziarek.com
Thu Sep 9 12:12:39 EDT 2004


You are completely right. I am real big into UI usability, and settings that
don't apply to one's situation should absolutely be hidden / removed. I
often have the problem, since I am really nothing more than an end user,
balancing out the idea between creating a polished end user experience and
this being very much a tinker toy that is still in heavy development. I
often want to suggest things that are purely aesthetic, but would make the
program nicer, but don't because I do not want to start the war between form
and function. 

That all said, I think that "asking only when there is actually a decision
to be made" sounds like a pretty straight forward goal, and I would love to
see it implemented into some future release of Myth. However, if that takes
away from someone who might be working on adding, oh, I don't know, AAC
support to MythMusic or something, well, I don't know if the trade off would
be worth it =)

Nate


> From: Jeremiah Morris <jm at whpress.com>
> Reply-To: Development of mythtv <mythtv-dev at mythtv.org>
> Date: Thu, 9 Sep 2004 11:50:52 -0400
> To: Development of mythtv <mythtv-dev at mythtv.org>
> Subject: [mythtv] RFE: conditional UI settings presentation
> 
> As the new mythui library will be a big post-0.16 push, I wanted to
> bring up something that I feel is lacking in the current presentation.
> All of the settings are present, even when they are inappropriate.   In
> some cases, it is known at compile time that the settings can never be
> used.  I would like to see these options hidden or removed when they
> are irrelevant to the user's situation.
> 
> The UI decision can take place either at compile time or at run time.
> An example is the screen for PVR-350 options.  If the ivtv config flag
> is disabled, then Myth knows at compile time that I will never use a
> PVR-350.  It doesn't even have to build that code.  If ivtv is enabled,
> I still may not have a PVR-350 installed; at run time, it could execute
> a check for the required hardware, and skip the screen if a 350 is not
> found.  Ultimately, I'd like to see both types of checks in place,
> although the compile-time decision is much more straightforward and
> would be a big help by itself.
> 
> As the audience for MythTV grows and its capabilities become more
> fragmented, this will become more important.  The dynamic menu
> structure (based on which plugins are loaded) is a good start, but
> applying this principle at a finer level will lead to less user
> confusion.  I find myself toggling settings that do nothing on my
> setup; the situation is worse on Windows and OS X, where hardware
> abstraction makes many of the choices meaningless.
> 
> I've spent very little time in the UI code, so if you've already
> thought about this, well, I'm glad.  :)  I know it makes a tough job
> tougher, but I hope that a future release of Myth will only ask the
> user when there's really a decision to be made.
> 
> - Jeremiah
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev




More information about the mythtv-dev mailing list