[mythtv-users] Watch Recordings doesn't list size of single recording

[R. G. Newbury]

On 12/16/2015 10:33 PM, Michael T. Dean wrote:
> On 12/16/2015 09:34 PM, Nicolas Riendeau wrote:
>>> Unfortunately, the mainline coders have used some library routines which
>>> make it even harder for you. So on the Upcoming Recordings page we get
>>> 'Today' and Tomorrow instead of the 'shortdate' 12-13 (or Sunday 12-13'.
>>> That "feature" is buried in the code, NOT in the theme....
>>
>> I have a scoop for you, they are also planning to add ereyesterday and
>> overmorrow too...
>>
>> Kidding obviously...  These are obsolete words for the day before
>> yesterday and the day after tomorrow...
>>
>> The dev(s) which did that did not do that to bug people, they thought
>> it would be better that way just like you think it would be better to
>> use ISO formats which we can  understand but don't normally use...
>>
>> And as far as I am concerned it should *not* be settable in the code
>> *nor* in the theme, it should be made configurable by the user.
>>
>> I know some of the devs do not like adding settings (my guess is that
>> it soon becomes hard to know what is use for what, etc...) but things
>> like that should be configurable I believe.
>
> The main problem with adding settings is that they're often added such
> that they make the exact same feature behave differently for different
> people, resulting in different code paths being followed due to the same
> user action.  This makes it very difficult to test, maintain, and even
> to identify/reproduce bugs that are reported. Usually this
> approach--adding a setting to make an action behave differently for
> different people--is taken when the developer can't decide how something
> should work.  The better approach is for the developer to make a
> decision and code it that way or--if all else fails--code both actions
> and allow any user to use either without having to flip some hidden
> setting somewhere.
>
> When it comes to a setting to determine date/time or other display
> formats, this is perfectly acceptable--and even sensible--because it's
> actually just remembering a user preference.
>
> Other settings fails that we still need to clean up are key bindings
> that masquerade as settings (i.e. changing behavior resulting from a key
> press via settings, rather than making both behaviors available via key
> bindings), settings that break functionality (i.e. such as "Browse
> Filesystem (slow)"), settings that should never be used (i.e. are used
> only to hide some system misconfiguration--when fixing the
> misconfiguration would be the more sensible approach--such as "Video
> aspect override", or similar), and others that I'm forgetting at the
> moment.
>
>> These settings should I think actually be configurable (and saved)
>> from the page they are related to (if applicable).
>
> Yes, nearly all of our "real" (good/should be kept) settings should
> become "live" settings--such that they can be changed where they're used
> and the change is remembered automatically--not buried in some far-off,
> easily-forgotten, hard-to-find settings page where the difference isn't
> easily observed.  The configuration (i.e. system-specific information
> usually not stored in the settings table, such as Video Sources, Capture
> Cards, etc.--generally the "one-time setup" stuff) is about the only
> stuff that belongs in a dedicated "settings" area.

Nick and I are generally on the same page. I think that the back end 
should use ISO standards for things like date/time. What the user wants 
should be set at the frontend. If no descriptive adjectives/nouns are 
used in the code, then translations  also work much better. In fact then 
both code and translations would then conform much more closely to the 
i18n intended standard: Data and naming/descriptions do not overlap.

It occurs to me that were this sort of coding structure used, then 
locale settings would take care of a large part of the "problem".

Geoff