[mythtv-users] 0.22 upgrade makes people searches case-sensitive

[f-myth-users at media.mit.edu]

    > Date: Fri, 20 Nov 2009 23:51:39 -0500
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > Only names are case insensitive.  Values are--as they always have 
    > been--case sensitive.

Okay, now I'm confused, because you and Robert seem to be saying
different things.  His response seems to indicate that all four
possibilities in the 2x2 crossbar would work; yours indicates
(I think!) that only these will work correctly:
   mythfrontend -O ThemePainter=opengl
   mythfrontend -O themepainter=opengl

The reason I asked, btw, is because these options are typically used
during debugging and, if I understand correctly, getting it wrong
means they're silently ignored---we saw that when this first came
up, because some user got it wrong on both sides of the equals sign.
Having options silently ignored due to case issues (especially when
the rules were different on the LHS vs the RHS) is a good way to
really raise the debugger's cognitive load---never a good thing.
[And it slows him down 'cause he has to ask for help, and raises
the traffic on the list...]

    > 			   Some values /must/ be case sensitive (such as 
    > those containing file/path information) and there's really nothing to 

Right.

    > distinguish them from ones that don't need to be, so we can't just 

Well, unless we had some sort of flag indicating that, but that'd be
quite a complication to the code I assume.  (I haven't looked into
how many places need to know.)

    > toLower() everything.  And, IMHO, it's not worth the effort to add--let 
    > alone maintain--the extra code required to allow a way to identify some 
    > settings as case-sensitive values and others as case-insensitive.

Certainly I think there'd be more leverage in documenting it instead.

    > The settings overrides are /not/ designed to be user-friendly.  They're 
    > really designed as a means of temporarily changing a value when 
    > something bad happens.  Note, also, that mythfrontend --help doesn't 
    > list any of the -O settings names you can use.  Therefore, it requires a 
    > knowledge of code to use them, and using them properly requires a very 
    > good understanding of the code.  (If you don't believe me, try 
    > overriding the NoPromptOnExit for mythfrontend.)

I believe you---I was just trying to figure out if there was a way of
making the life of someone trying to debug (therefore using them) easier.

    > I don't think you'd argue that a new user isn't going to intuit that if 
    > they change the theme painter to OpenGL and then restart mythfrontend 
    > and it doesn't start  that they need to restart with:

    > mythfrontend -O ThemePainter=qt

No, but the case distinctions are easy to miss and/or mess up, and
we've seen that.  If there was an easy way to keep the user from
shooting himself in the foot, it seemed to be a nice thing to do.
(And it seems like the changeset you pointed to was exactly that
"easy and keeps the user from shooting himself" sort of thing.)

    > And, it's not the case-sensitivity that's preventing that.  Instead, 
    > they're going to have to do a search or or ask on IRC or something.  
    > When doing so, they should get the proper command to copy/paste to fix 
    > things up.  Therefore, I would argue, it's just not worth the extra code.

"Extra code" here means making values case-insensitive, right?

Yeah, probably not worth extra code, especially if some values must be
case-sensitive and the code has no way to know which.  But at least
wherever this sort of stuff -is- documented (e.g., in a "how to debug
problems with Myth" sort of document), you'd hope that things that are
(or aren't!) case-sensitive get called out, so the user knows where
to be careful and where he doesn't have to be.  (I don't necessarily
count "searching the archives" as that sort of documentation, because
it's so hit-or-miss, especially because it's so hard to tell if
something was wrong-as-stated, right-once-but-wrong-now (superceded),
or if you've simply missed it entirely because you didn't use the
right search terms.  So I was thinking of the wiki or the release
notes or something when I asked "documented".)

[I also didn't think it'd turn into this much of a conversation,
really.  It seemed like a simple question with a simple answer.
*sigh*]