[mythtv] Ticket #9556: Updated enhanced cutpoint edit functionality patch

[Bill]

On 02/14/2011 07:59 AM, MythTV wrote:
> #9556: Updated enhanced cutpoint edit functionality patch
>
> Comment (by markk):
>
>   Bill
>
>   This is a big patch and I haven't had a chance to try and get it working
>   with trunk, so please forgive me if I've missed something.
>
>   Can you clarify what additional features this adds? (over and above the
>   obvious of providing the extra frames). Implementation details aside, this
>   is a lot of code for what appears to be a small amount of fairly niche
>   functionality - and something that adds additional overhead for a fully
>   completed theme.
Thanks for taking a look at it, Mark.

This gives the user a better view of where they're cutting and speeds up 
editing.

For example, take the process of saving programs without commercials:  
This requires going into the editor, loading the comm-flag list and 
adjusting the cutpoints for errant flags.  When doing this I often flick 
back and forth to see the adjacent frames. It's kind of like having 
tunnel vision.  This lead to my original patch in #6322 - the basic 
functionality to display the current frame and the immediately adjacent 
frames.

Later I found the adjacent frames are useless when navigating through 
the recording. It's more useful to see the next few frames I'll seek to, 
then I can lower the seek amount to fine tune the cutpoint. Kind of like 
zoom in / zoom out.


>   Implementation wise:-
>
>   - I'd personally rather see this displayed and themed as part of the OSD.
>   This seems the most logical place to handle it (we already have the
>   current frame on screen), avoids the extra main UI integration (and the
>   complications involved) and makes it a little more future proof (the
>   implementation of guidedrid etc causes many problems and it needs
>   changing).
>
>   - I'm not sure I see the utility of displaying a series of frames that
>   are, for example, 60seconds apart. frame by frame yes - but otherwise it's
>   just confusing.
>
>   - If you stick to the next and previous X frames, you by and large have
>   these available already - or at least it would take relatively little work
>   to ensure that you have a buffer of 11 frames, and re-position to the
>   middle.
>
>   All told, I think I can see a far simpler solution that hence is more
>   maintainable and, if done properly, requires minimal theming. Unless I've
>   missed the point...
>
Valid points. As always, you guys are welcome to do whatever you want 
with this. I'll help where I can if there's interest in getting it into 
trunk.