input.conf: rotate with r and t, move subs with ctrl+up and down

[guidocella]

Rotating videos is a commonly needed feature and the command do it is not obvious, so bind it by default. r and t are chosen because:

• r is the first letter of rotate
• t is the third and fifth letter of rotate
• They are next to each other, so it is intuitive that the left key rotates left and the right key rotates right

Move add sub-pos to ctrl+up and down, because it was hard to remember which of r and t moves up and which moves down, while with arrow bindings it is obvious, and because ctrl{,+shift}+{left,right} already have sub bindings.

Fixes #5458.

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-14-arm
• mpv-macos-12-intel
• mpv-macos-13-intel

[kasper93]

Likely will be hard to convince everyone on this change.

[na-na-hi]

This closes https://github.com/mpv-player/mpv/issues/5458, as all other bindings are already added.
Following the original feature request, I think it's better to bind them to Alt modifier, which is currently not overcrowded.

[guidocella]

Alt+left and right change video-pan, so we have to choose between ctrl+alt+arrows, alt+shift+arrows and r.

[na-na-hi]

we have to choose between

Why not Alt+r and Alt+t? They aren't used and fit in your line of reasoning.

[guidocella]

There would be no advantage over using r and t directly?

[na-na-hi]

The advantage is by not breaking key bindings introduced and unchanged since 2002: https://github.com/mpv-player/mpv/commit/6a446870

[guidocella]

Oh right. Well as I wrote I never liked those bindings anyway because I can't remember which moves subs up and which moves them down without trying both, and I think ctrl+up and down are much more intuitive. And it's better not to overload one key with modifier bindings which are harder to press when we can have them on separate keybindings which are still mnemonic. Alt+s and Alt+v are the only letters with Alt bindings, and it's because they have other bindings related to the same functionality on those keys, while sub-pos and rotate are completely unrelated.

[na-na-hi]

Alt+0/1/2 aren't related to 0/1/2 in functionality at all either.

Whatever key you decide to use, I think rotation, which can change the window position and dimension, should be placed behind a modifier just like Alt+0/1/2.

[kasper93]

I never liked those bindings anyway because I can't remember which moves subs up and which moves them down

And how would you remember what way r or t rotate? Especially that r is backward? Exactly the same problem. It is intuitive that r is a rotate and most common is clockwise. It is NOT intuitive that t is rotate t is the third and fifth letter of rotate is not something anyone would infer without memorizing the documentation, which can be already said about sub-pos. But after 20 years people might have already memorized sub-pos key binds.

and I think ctrl+up and down are much more intuitive

Yes and the exactly same thing apply to rotate.

we can have them on separate keybindings which are still mnemonic.

You can say that about sxiv for example uses < and >, but for r t it no longer is that simple to memorize.

I personal think ctrl+r and ctrl+shift+r meets all the requirement for rotate, easy to remember, established by other software, less commonly used keybind of counter-clockwise is also accessible. Not breaking old keybinds. Also should consider adding the

Ctrl+Alt+r  add rotate +1
Ctrl+Alt+R add rotate -1

also reset keybind would be nice and this is getting crowded by keybinds.

tl;dr I don't mind new keybind whatever it is, only issue is that I don't understand why sub-pos has to be changed.

I know nowadays keyboards don't have numpads, but I still use it for paning video like this https://github.com/mpv-player/mpv/issues/12083#issuecomment-1666831514

[guidocella]

And how would you remember what way r or t rotate? Especially that r is backward? Exactly the same problem. It is intuitive that r is a rotate and most common is clockwise. It is NOT intuitive that t is rotate t is the third and fifth letter of rotate is not something anyone would infer without memorizing the documentation, which can be already said about sub-pos. But after 20 years people might have already memorized sub-pos key binds.

As I wrote multiple times, by the fact that the left key rotates left and the right key rotates right, and by the fact that with all other coupled key bindings (current r and t, w and e, z and x, 1 and 2, 3 and 4, 5 and 6, 7 and 8), the left one decrements and the right one increments. t being in rotate is just a bonus secondary coincidence. But compared to these other keybindings, sub-pos requires the extra mental step that you have to figure out which between decrementing and incrementing is up and which is down, and it's faster to just ty to press both r and t IMO.

and I think ctrl+up and down are much more intuitive

Yes and the exactly same thing apply to rotate.

Except both ctrl+left and right and alt+left and right are already bound. I don't think ctrl+alt/alt+shift bindings are easier to remember than r.

we can have them on separate keybindings which are still mnemonic.

You can say that about sxiv for example uses < and >, but for r t it no longer is that simple to memorize.

I think r for rotate is easier to remember than <. Sxiv has < and > because r is bound to reloading the image.

I personal think ctrl+r and ctrl+shift+r meets all the requirement for rotate

I guess we will need a poll if everyone prefers different bindings.

[kasper93]

I guess we will need a poll if everyone prefers different bindings.

I'm throwing ideas, I think your approach makes sense, but the reason to replace already established key bind for sub-pos seems weak. It is not like mouse wheel seek control that was pretty commonly disliked.

r/R makes it inconsistent with the rest of the layout

@llyyr note that there is already precedence with that style of commands. So it is not as inconsistent as you think.

#j cycle sub                            # switch subtitle track
#J cycle sub down                       # switch subtitle track backwards

[guidocella]

the reason to replace already established key bind for sub-pos seems weak. It is not like mouse wheel seek control that was pretty commonly disliked.

It may just not be commonly used. I don't actually use it either (why would you need to move subs at runtime?) and I also had to change it to add sub-margin-y to even make it work with --sub-align-y=top (side note: why do --sub-pos docs say that --sub-margin-y is better, and --sub-margin-y docs say that you should use --sub-pos? lol). Another reason the r binding is bad is that letter r has nothing to do with sub-pos. I don't think we shouldn't have the best possible bindings to preserve a binding that makes no sense, is hard to use compared to up and down arrows, and may not even be used much.

r/R makes it inconsistent with the rest of the layout

@llyyr note that there is already precedence with that style of commands. So it is not as inconsistent as you think.

#j cycle sub                            # switch subtitle track
#J cycle sub down                       # switch subtitle track backwards

Actually it wouldn't be bad to also bind k to cycle sub down. All letter add bindings have both side-by-side bindings and upper case ones (R/t, W/e, Z/x), where the left one decrements and right one increments, which I replicated. All number add bindings are only side-by-side keys, and even [ ] to multiply speed is a similar case. We also have F to decrease sub-scale and G to increase it.

[guidocella]

We can even bind ctrl+shift+up and down to add secondary-sub-pos now that it's being added. This wouldn't be possible if we cram everything on r, and it complements the ctrl and ctrl+shift left and right sub bindings well.

[na-na-hi]

On the most "logical" key binding for subtitle positioning

Based on the pattern here...

#RIGHT seek  5                          # seek 5 seconds forward
#LEFT  seek -5                          # seek 5 seconds backward
#UP    seek  60                         # seek 1 minute forward
#DOWN  seek -60                         # seek 1 minute backward
#Shift+RIGHT no-osd seek  1 exact       # seek exactly 1 second forward
#Shift+LEFT  no-osd seek -1 exact       # seek exactly 1 second backward
#Shift+UP    no-osd seek  5 exact       # seek exactly 5 seconds forward
#Shift+DOWN  no-osd seek -5 exact       # seek exactly 5 seconds backward
#Ctrl+LEFT   no-osd sub-seek -1         # seek to the previous subtitle
#Ctrl+RIGHT  no-osd sub-seek  1         # seek to the next subtitle
#Ctrl+Shift+LEFT sub-step -1            # change subtitle timing such that the previous subtitle is displayed
#Ctrl+Shift+RIGHT sub-step 1            # change subtitle timing such that the next subtitle is displayed

Ctrl/Shift+direction keys all have the meaning of seeking and timing. In fact, so do all Shift/Ctrl+any non-letter key. The only logical choice of Ctrl/Shift+UP/DOWN here would be doing the same thing as Ctrl/Shift+LEFT/RIGHT with the parameter changed to -5/5. So binding Ctrl+Shift+UP/DOWN to subtitle position isn't consistent.

On the other hand...

#Alt+left  add video-pan-x  0.1         # move the video right
#Alt+right add video-pan-x -0.1         # move the video left
#Alt+up    add video-pan-y  0.1         # move the video down
#Alt+down  add video-pan-y -0.1         # move the video up

Alt+direction keys move the video position. Other than "move subtitles up/down" they're the only key bindings that have the meaning of moving in physical coordinates. All other Alt+non-letter keys change the video size.

Based on these predicates, Ctrl+Alt+UP/DOWN to move subtitle position, and Ctrl+Alt+LEFT/RIGHT to move secondary subtitle position (to avoid 3 modifier keys), would be the most "logical" choice...

Or just bind secondary subtitle position to Alt+r/t instead:

• Doesn't break existing key bindings.
• Consistent with existing binding of v and Alt+v, where Alt means "secondary".
• Less modifier keys than the most "logical" choice.

On the most logical key binding for rotation

The overwhelming majority of key bindings for moving and zooming all use Alt modifier. The remote exception is w and e for panscan, but that only zooms video situationally.

This strongly suggests using Alt+non-letter for rotation. Unlike panscan, rotation can be destructive to window position and size. Reverting a rotation doesn't always go back to the original position or size because the window manager can resize and clip the window inside monitor bounds after rotation.

[guidocella]

Ctrl/Shift+arrows bindings may be timing related, but sub-step is already different from seek and is closer to z/Z/x, and sub-pos is at least related to subs like sub-seek and sub-step.

Keybindings like Ctrl+UP sub-seek 5 are consistent, but useless, so Ctrl/Ctrl+Shift + UP/DOWN are left available, and I don't see what we could ever use them for that only needs up and directions other than changing sub-pos or sub-margin-y, let alone a feature that only needs up and down directions that is related to subs. I would prefer keybindings with fewer modifiers than to have each modifier handle exactly one group of functionalities, which is already not the case anyway if you consider non-arrow bindings Ctrl+s, Ctrl+w, Ctrl+c, Shift+letters, Shift+3/#, Shift+-/_, Alt+v, Alt+s, w/W/e. For example it took me a long time to memorize which is sub-seek and which is sub-step between Ctrl and Ctrl+Shift, while I quickly memorized every keybinding without modifiers. Ctrl+Alt + LEFT/RIGHT to move up and down are as unintuitive as r and t.

Or just bind secondary subtitle position to Alt+r/t instead:

We would also have to bind Alt+Shift+r because the t binding makes no sense on non-QWERTY layouts, which I assume is why the manual says e, t and x are discouraged, so that would still have multiple modifiers.

[na-na-hi]

I would prefer keybindings with fewer modifiers than to have each modifier handle exactly one group of functionalities, which is already not the case anyway if you consider non-arrow bindings

I addressed that in my previous post for the case of non-letter keys, where no "technical debt" has been introduced yet, unlike for letter keys.

Nevertheless, the advantage of using Ctrl+Shift+UP/DOWN for subtitle position is questionable, as using Alt+r/t would have less modifiers (therefore easier to memorize) while not breaking existing bindings.

We would also have to bind Alt+Shift+r

Agreed, to be consistent with existing R binding.

because the t binding makes no sense on non-QWERTY layouts, which I assume is why the manual says e, t and x are discouraged

The reason why they're discouraged is because they're the only letter bindings which use adjacent keys for increment and decrement. However, unlike z/x and w/e which aren't adjacent on common QWERTZ and AZERTY keyboards, r/t are always adjacent on all common keyboards (even dvorak has r and t adjacent), so I think the use of r/t for increment and decrement isn't problematic.

[kasper93]

The reason why they're discouraged is because they're the only letter bindings which use adjacent keys for increment and decrement. However, unlike z/x and w/e which aren't adjacent on common QWERTZ and AZERTY keyboards, r/t are always adjacent on all common keyboards (even dvorak has r and t adjacent), so I think the use of r/t for increment and decrement isn't problematic.

I agree and in fact initially I wanted to mention that, but r/t are more often than not next to each other. And if someone is using exotic things like Colemak, they might as well rebind the keys...

EDIT: Also I want to make remark about keybinds in general. They are not accessible for most people. Only those common, easy to remember, make sense. You know like fullscreen/pause/(rotate). Going deeper into obscure commands like sub-position, even if you may need it once a year you will likely forget what was the key for it. I find it way easier to memorize keys that I assign myself, because it is how my brain connected the key to functionality. So trying too hard to make sense of of default layout may not be that important. I mean we should focus connect simple commands to simple keybinds and the more advanced things can be left less usable. Not sure if you get what I'm trying to say, but keybinds are not something new user will understand anyway.

[na-na-hi]

Also I want to make remark about keybinds in general. They are not accessible for most people.

New users will search "mpv keyboard shortcuts" (because it's needed for anything that can't be done with the mouse), and click on the first result which is the mpv manual, with default keyboard controls right on the top of the page. So the default keybindings are indeed easily accessible, and they will learn these keybinds instead of making custom ones because for them it's the path of least resistance.

Only those common, easy to remember, make sense. You know like fullscreen/pause/(rotate). Going deeper into obscure commands like sub-position, even if you may need it once a year you will likely forget what was the key for it.

Whether rotation is more commonly used, "simpler", or "less advanced", than subtitle position is purely determined by individual users' needs. Users who primarily watch subbed TV shows with subtitles of varied sources and qualities, rather than random camera captures, would use the latter more frequently.

[na-na-hi]

Still personally leaning towards Alt+r/t, but if enough people think r/t is fine then I don't mind.

Also currently the keybinds don't work properly if video-rotate isn't exactly 0/90/180/270. If I set it to 179 and press r, it rotates to 270 instead of 89 or 90.