[mythtv] Improving playback groups

[Jim Stichnoth]

On Sun, Feb 14, 2010 at 10:55 AM, David Engel <david at istwok.net> wrote:
> Hi Jim,
>
> The suggestion to greatly extend playback groups comes up
> periodically.  I don't know about the other developers, but I've yet
> to hear a suggestion that I like for a couple of reasons.
>
> First, there is the difficulty in deciding which parameters should be
> included and which ones shouldn't.  I wrote the feature specifically
> for the skip ahead amount and the default timestretch speed.  That
> should be enough for everyone, right? :)  OK, I did make the API
> extensible, but I honestly didn't expect it to be done much, if at
> all.  In my current opinion, any significant extension needs to
> cleanly and simply handle virtually any playback related setting.
>
> Second, and probably much more importantly, the UI needs to add more
> value than complexity.  For example, the multi-level, nested scheme
> you described sounds great in theory, but I really can't see it
> working well in practice.  I've used applications that implemented
> such a scheme and it was always a pain to move around several dialogs
> or tabs to see the small handful of settings that were changed from
> the parent settings.  IMO, any UI needs to make it easy to quickly
> identify all settings that are changed from the default (or parent).
>
> I haven't given this a lot of thought, but I'm going to throw out an
> idea for s simple UI to handle a greatly extended playback groups
> feature.  What if the guts of the interface was simply a multi-line
> text box for listing key=value pairs to override the default settings?
> No, it wouldn't be idiot proof, but it would be simple, make it easy
> to see exactly what settings are changed and be immensely flexible.

Hi David,

Thanks for reading through and commenting.  I've been slowly working
on an implementation, and it's really great as far as playback goes.
You're right that the UI design is the tricky part.

I implemented a hierarchical model where all roots implicitly inherit
from the Default group and Default inherits from the host-specific
settings.  I find that the Default group may override a lot of
host-specific settings because I prefer many changes from the myth
default, whereas non-Default groups need only a few changes from
Default.  So it's probably reasonable to limit the hierarchy to
Host>Default>{all groups}.

For the settings UI, I am trying to reuse the code in the
PlaybackSettings and OSDSettings classes, where I think all the
relevant playback settings are located.  However, some of those
settings are not really relevant to playback, such as pages 4, 5, and
6 of Playback Settings as well as several on page 1.  Reusing the code
will give a layout that is familiar and similar to the existing
settings UI, which would be helpful to that handful of people who
actually remember where the settings are. :)  As you say, this needs
to be made so that it is easy to clearly call out settings that are
overridden, and I'm working on that.

I like the idea of an "expert mode" to give direct access, though it
comes with its own challenges, such as finding the names of all
settings that are covered by expanded playback groups.

Jim