Tweak to Disable Media Preview Shortcuts

[TheQwerty]

v7.90.0017 - 2008-12-21 22:04
...
+ Media Preview: Added keyboard-driven backwind and forewind. Works
in paused and running mode, on audio and video.
Left: Frame step backward (Audio: 100 msec backward)
Right: Frame step forward (Audio: 100 msec forward)
Shift+Left: 1 sec backward
Shift+Right: 1 sec forward

I'm really surprised that it seems no one has complained about this or reported it as a bug in the year+ since it was introduced, but these shortcuts break standard keyboard navigation of the list when the preview tab is visible; even if XY gives you a "cannot decode" error for the file (yay ID3v2.4 ).

Since I'm apparently the only one in the world to have been bothered by this (and only 388 days after it was born), I'm just requesting a tweak to disable these shortcuts.

But I would think it would be better to not break navigation by default and ideally these would be commands in CKS.

[admin]

v7.90.0017 - 2008-12-21 22:04
...
+ Media Preview: Added keyboard-driven backwind and forewind. Works
in paused and running mode, on audio and video.
Left: Frame step backward (Audio: 100 msec backward)
Right: Frame step forward (Audio: 100 msec forward)
Shift+Left: 1 sec backward
Shift+Right: 1 sec forward

I'm really surprised that it seems no one has complained about this or reported it as a bug in the year+ since it was introduced, but these shortcuts break standard keyboard navigation of the list when the preview tab is visible; even if XY gives you a "cannot decode" error for the file (yay ID3v2.4 ).

Since I'm apparently the only one in the world to have been bothered by this (and only 388 days after it was born), I'm just requesting a tweak to disable these shortcuts.

But I would think it would be better to not break navigation by default and ideally these would be commands in CKS.

Not "when the preview tab is visible" but when a media file is previewed. Why should anybody be bothered? Shift+left/Right are not very common keys anyway.

[TheQwerty]

Not "when the preview tab is visible" but when a media file is previewed. Why should anybody be bothered? Shift+left/Right are not very common keys anyway.

Fine, but it's also not when a media file is previewed either.. it's any time XY attempts to preview a media file. If the file cannot be decoded it still renders left/right useless for navigation.

Left/Right are very common keys, a lot better than using Up/Down to switch columns in the non-Details views, and if you want to extend a selection to the next or previous column you're going to wish Shift+Left/Right worked.

In either case I bet they are both used more often than rewind/fast-forward. Not only because the times when they are valid for navigation far out number the times when rewind/ff are possible, but also because their behavior makes much more sense for moving around the list than they do for shifting time.


To be perfectly honest, I don't feel there is any excuse at all for breaking the list navigation standard. It results in a very confusing scenario, where the behavior of the focused control changes based on another, but only sometimes, including a case when the control now using left/right isn't even visible.

If you ask me I was being nice only asking for a tweak to correct this, because it's atrocious form to break a convention in this way.

[admin]

Not "when the preview tab is visible" but when a media file is previewed. Why should anybody be bothered? Shift+left/Right are not very common keys anyway.

Fine, but it's also not when a media file is previewed either.. it's any time XY attempts to preview a media file. If the file cannot be decoded it still renders left/right useless for navigation.

Left/Right are very common keys, a lot better than using Up/Down to switch columns in the non-Details views, and if you want to extend a selection to the next or previous column you're going to wish Shift+Left/Right worked.

In either case I bet they are both used more often than rewind/fast-forward. Not only because the times when they are valid for navigation far out number the times when rewind/ff are possible, but also because their behavior makes much more sense for moving around the list than they do for shifting time.


To be perfectly honest, I don't feel there is any excuse at all for breaking the list navigation standard. It results in a very confusing scenario, where the behavior of the focused control changes based on another, but only sometimes, including a case when the control now using left/right isn't even visible.

If you ask me I was being nice only asking for a tweak to correct this, because it's atrocious form to break a convention in this way.

You don't happen to have an alternative suggestion for those keys. Is there any standard out there?

[TheQwerty]

You don't happen to have an alternative suggestion for those keys. Is there any standard out there?

I can't really think of anything for time-shifting other than the multimedia keys; MediaNextTrack, MediaPreviousTrack.

I'm not sure what the default shortcut list is like, but I could see it making some sense using:
'<>' (or rather ',.') or '[]' or even '-='.
However, they could be used in filenames for jumping, so you should probably use modifiers.

But again I'm not really aware of a different standard. Many of the players probably accept Left/Right, but I doubt many of them also use those for navigation (or they require modifiers).

Adding them to CKS absolves you of having to worry about standards though.

[admin]

You don't happen to have an alternative suggestion for those keys. Is there any standard out there?

I can't really think of anything for time-shifting other than the multimedia keys; MediaNextTrack, MediaPreviousTrack.

I'm not sure what the default shortcut list is like, but I could see it making some sense using:
'<>' (or rather ',.') or '[]' or even '-='.
However, they could be used in filenames for jumping, so you should probably use modifiers.

But again I'm not really aware of a different standard. Many of the players probably accept Left/Right, but I doubt many of them also use those for navigation (or they require modifiers).

Adding them to CKS absolves you of having to worry about standards though.

Adding them to CKS is not possible. Next version has a tweak DisableMediaPreviewShortcuts. I will document it when the second fool raises his head.

[TheQwerty]

That's fine!
But how many would it take to invert the default value and the tweak's logic?

[admin]

That's fine!
But how many would it take to invert the default value and the tweak's logic?

3

[PeterH]

That's fine!
But how many would it take to invert the default value and the tweak's logic?

You say: name it EnableMediaPreviewShortcut?
And 0 will disable, 1 will set left/right, 2 will set ,/., 3 for <> (Just an idea...)

But some of these combinations are bad, as they are language dependent: for example on german keyboard - and = are on complete different places. (= is shift-0)

But maybe 4 means the media keys? (If that's possible?)

[TheQwerty]

You say: name it EnableMediaPreviewShortcut?
And 0 will disable, 1 will set left/right, 2 will set ,/., 3 for <> (Just an idea...)

But some of these combinations are bad, as they are language dependent: for example on german keyboard - and = are on complete different places. (= is shift-0)

But maybe 4 means the media keys? (If that's possible?)

Close to what I meant, but only with 0 and 1 being possible, and 0 being the default.

My suggestions weren't good (I agree!), and unless someone else knows of a better standard aside from the multimedia keys there isn't really a better option for Don to use to still have both set of commands be easily accessible.

The only other option I see would be to add a way to "focus" the Media Preview, add a CKS to do so, and then add an option to automatically focus that when previewing an item. But that's a bit clucky to go between controlling the media and navigating the list, and you still have left/right having multiple contextual duties.

That's why putting them all in CKS would be best, but if that's not possible, then it's a tough spot.