[mythtv] Ticket #6813: Patch to manage upcoming recordings from the "Watch Recordings" screen

[Michael T. Dean]

On 04/15/2010 10:25 PM, Bill wrote:
> On 04/15/2010 01:33 PM, MythTV wrote:
>>   A very sincere thank you for your work on this.  After some discussion
>>   amongst the developers, we've decided this isn't exactly the 
>> direction we
>>   want to go with the Watch Recordings screen.  We *do* want to 
>> consolidate
>>   some of the screens together (the recording title/people/etc. 
>> searches)
>>   but the current and upcoming recordings from a user interface point of
>>   view just don't feel natural to us.
>>
>>   Some other random commentary that might be useful to you in the 
>> future:
>>
>>   * We're trying to move away from the "number button = change view"
>>   functionality.  We'd rather allow for friendly menus that have the 
>> user
>>   selecting the view from a plain-english list.
>>
>>   * It would be nice to avoid "generic" topline/midline/bottomline 
>> stuff, it
>>   implies a fixed/strict layout we're trying to avoid with MythUI.
>>
> No problem Robert, thanks for considering it.
>
> Two questions:
>
> 1. What's your (developers') opinion on ticket #8328?
> 2. I get your points on the "number button" and generic stuff you 
> mention above. I have a number of patches from 0.21 with this type of 
> logic that I'm now porting to trunk.  Is there any preferred way of 
> attaching a hotkey to these menu options?

My plan is to remove the "generic keybinding overloads" completely 
and--where it makes sense--have specific keybindings that users can 
manually bind for the secondary actions (i.e. no default bindings).  
Reusing generic keybindings for purposes completely unrelated to the 
action name and the key's usage in other parts of MythTV makes usage 
difficult.  The "specific" keybindings will use sensible action 
names--ideally, names that are used for similar purposes in other 
contexts/areas.

For example, it would make sense to use PREVVIEW/NEXTVIEW to cycle 
through different views in any part of MythTV.  We don't currently have 
any sort-related action names (and using PREVVIEW/NEXTVIEW for sorting 
sometimes and for changing the view other times would be just as 
confusing as using random generic bindings for sorting), so for sorting 
it may make sense to create a whole new a NEXTSORT/PREVSORT binding, or 
if it's determined that having a specific key for specific sorts is 
desirable, actions like SORTTITLE, SORTTIME, ... may be sensible (where 
the names are just-generic-enough to be reusable, but not so generic as 
to be meaningless).  This would be /much/ better than having action 2 be 
bound to sort by title.

Basically, though, if you can say, "There's no possible way anyone would 
just think, 'Oh, maybe if I hit 7 it will sort by last record date,'" it 
needs to be a user-specified key binding.

And, as Robert mentioned, if it's a common/useful action, it definitely 
needs to always be available through the menu (even if you make the 
optional keybindings available).  See the Set Priority/Manage Rules 
screens for a nice example of the sort menu (IIRC, nicely implemented by 
Paul H.) and an example of what /not/ to do for bindings ;) (where the 
bindings were done that way due to limitations that no longer exist due 
to a vast number of improvements across the board--so aren't really 
anyone's fault, but are something I want to break away from doing, and 
even fix the existing occurrences of).

Note, though, that some of this will require some changes to make it 
easier for users to map these keys (such as modifying MythControls to 
allow overrides where appropriate--and modifying the keybindings 
themselves to alert MythControls when overrides are appropriate).  These 
changes are on my TODO list, but I'm likely to get to that after 
cleaning up some of the keybindings usage.

Mike