Cleanup of default key bindings (second try)

[ghost]

This should be eventually done. But this time, my opinion is that we shouldn't gratuitously change bindings just because.

There are some things that really should be changed and everyone agrees about, such as remapping o.

Some suggestions are controversial, like mapping ESC to exit fullscreen.

Anyway, let the bikeshedding begin.

[giselher]

The keys for next and previous chapter (@ and !) should be changed. Those are one of my most use keys and I have remapped them to 'a' and 's' for convenience.

I rather use [ and ] (currently playback speed) or HOME (POS1) and END for this.

[ghedo]

The c key is pretty annoying (the only time I use it is when I hit it by accident). This also came up in the previous discussion IIRC.

The same applies to w and e though they are probably more useful.

[qmega]

For chapters, I use Ctrl-Left/Right and the back/forward buttons on my mouse (BTN7/8), but both of those only work when there's a vo window.

I have HOME no-osd seek 0 absolute-percent exact to go to the beginning of the file. I think that's fairly intuitive and might be worth being default.

As for ESC, I think exiting fullscreen is what people would expect it to do. Personally, I have it mapped to quit_watch_later.

Also, I agree that some of the rarely used things like c should be unmapped or moved.

[divVerent]

My personal list of mosy hated binds:

• change chapters
• change audio track
• change subtitle track

I always have to look these bind up in the manpage before use. Although I
have no constructive more intuitive idea for these...

[otommod]

Maybe change chapters with [ and ] like @giselher proposed and use a/A and s/S to cycle audio/subtitle tracks both ways. But then what about screenshots. Also, non-QWERTY layouts...

[bodayw]

Seems changing chapters is the most frequently used function here. I would also like the keys for previous/next chapter to be changed to more "intuitive" ones.

I don't know how often would people use pgup/pgdn to seek a file back/forward for 10 minutes, but to me it seems much more useful to change those to previous/next chapter.

But, there are no pgup/pgdn keys on a Mac keyboard...Maybe "[" and "]"? They are now binded to changing playback speed, which IMO are quite rarely used for most people.

Maybe also consider change the multimedia keys PREVIOUS and NEXT to changing chapters instead of seeking back/forward for 1 minute.

[ghost]

Removed c, remapped o.

Chapter seek should definitely remapped. Suggestions were:

• [, ] - not so good on all keyboards, and also occupied by speed changes.
• pgdn, pgup - ok, but doesn't exist on mac.
• ctrl+left/right - ok, but doesn't work on terminal

I think Ctrl could be made work on most terminals, though. What keys does the mac have again?

[ChrisK2]

pgdn, pgup is accessible as fn+down, fn+up on small Mac keyboards.

[mia-0]

On Sunday 03 August 2014 12:19:16 wm4 wrote:

pgdn, pgup - ok, but doesn't exist on mac.

Lies. fn+up/down.

I very much support this change. @/! is awful on non-US layouts.

[Hamuko]

Pgdn, pgup are accessible vial Fn on small Mac keyboards and are found standalone on the wired USB keyboard.

[ and ] are hidden behind Alt+8 and Alt+9 on my keyboard.

Also, if I don't remember incorrectly, Ctrl+Left/Right by default switches spaces left and right on OS X (if you have set up spaces).

[Nyx0uf]

p for pause is weird, all media players use space to pause, personally I remapped p to show_progress

[Argon-]

(I did so too)

[qmega]

I also have p mapped to show_progress.

[ghost]

So what does this mean? Is pgup/pgdown good to go for chapters?

[bodayw]

So what does this mean? Is pgup/pgdown good to go for chapters?

Personally it's more preferable to map single keys for seeking chapters, not key combinations, or at least key combinations can be pressed with one hand. So I would agree to make pgup/pgdown for this (which is already much better than shift+!/@), but since I only use mpv on my Mac, I still hope a pair of single keys could be used, ideally would cause minimum conflict with old key bindings while still intuitive (not easy).

Another suggestion aside from [ and ]: what about < and >? They are currently bound to navigating back/forward in the playlist.
Well maybe there are a lot of folks are using this for their playlists...So I really don't know.

[ghost]

what about < and >?

No, they're terrible. Some keyboards have them on the same key, and without shift it produces < (which is bad intuitively, because without modifiers you'd expect it to go forwards, not back). In fact, playlist navigation could use new bindings too.

[divVerent]

From my side - yes. Just like a for switching audio and s for subtitles.

BTW the av/as delay shortcuts can go. The few who need them (I sometimes
do) can use input.conf for them, and the end users better not be able to
accidentally screw up sync (as restoring to 0 is nontrivial).
Am 05.08.2014 01:21 schrieb "wm4" notifications@github.com:

So what does this mean? Is pgup/pgdown good to go for chapters?

—
Reply to this email directly or view it on GitHub
#973 (comment).

[Yomi0]

This should be eventually done. But this time, my opinion is that we shouldn't gratuitously change bindings just because.

There are some things that really should be changed and everyone agrees about, such as remapping o.

Some suggestions are controversial, like mapping ESC to exit fullscreen.

Anyway, let the bikeshedding begin.

What if when mpv was full screened, ESC would go back to being windowed, and pressing ESC again while windowed would exit mpv?

[ghost]

Remapped pgup/dwn, keeping the old chapter bindings.

What if when mpv was full screened, ESC would go back to being windowed, and pressing ESC again while windowed would exit mpv?

Perhaps, but then the bindings would be stateful, which would require additional code and more effort from the user to understand how it works.

[ghost]

Removed some bindings I deemed too obscure with commit 90ec333.

[Bilalh]

I also have p mapped to show_progress.

[ghost]

I also have p mapped to show_progress.

It'd be weird to have both o and p and P have mapped to the same key...

Why not restore 10min seek as Shift+PGUP and Shift+PGDWN ?

Opinions?

[bodayw]

For seeking I would prefer Left and Right mapped to 5 s back/forward instead of 10 s seeking. 5 s seeking back is ideal when you missed a line or a comment and want to go back, while 10 s is a bit too long.

[Hamuko]

I replaced 10 second Left and Right seeking with 5 second seek as well. 10 seconds is pretty long when you just need to get a quick glimpse at something. And it's not like you can't press the key twice.

[Bilalh]

I actually like Left and Right being 10s.

Also I use sub_seek all the time since it very useful when you miss a subtitle. I think it should have a mapping.

e.g I bound Shift+RIGHT no- sub_seek 1 and Shift+LEFT no-osd sub_seek -1

[ghost]

I'd be fine with reducing normal seeking to 5s (Personally I use 1s, which effectively make sit skip to the next/previous keyframes, but it sometimes gets "stuck" with some formats.)

e.g I bound Shift+RIGHT no- sub_seek 1 and Shift+LEFT no-osd sub_seek -1

I agree it should get a default binding, but I think these keys should remain normal precise seeks.

[Bilalh]

Also could you keep, the bindings for next and previous chapter (@ and !), since you can not press fn+up or fn+down (on a mac) with one hand.

[mvhulten]

It is great to see active development on a video player. I am an mplayer user and starting/occasional mpv user. I am probably expecting too much similarity between mpv and mplayer (as it is a different video player), and my critique comes a bit late, but I think that the following ideas may be worth putting into the discussion as mpv does not, it appears, stop being developed, which is a good thing!

Were there important reasons to remove keys for adjusting contrast, brightness and so on? I have seen the statement that it is better to change it on the hardware, but that is not really an argument to remove the functionality. If it resulted in less code to maintain, this is a good (but not sufficient) argument.

In general, my opinion is that there should be a very good reason for any change in the user interface, for any program. In this sense I also do not understand why it was necessary to change the 'o' key binding (OSD), or the ←/→ from a 10 s to a 5 s change. When any improvement is subjective or minor, I tend to respect the legacy. Am I getting old?

[FichteFoll]

Some things should be changed eventually to make them better. You'll never leave legacy or tech debt behind if you're resistant to change. While the whole key binding file could probably use an evaluation for each key, which would make adaption of that way easier (through a config option that uses the legacy bindings by default during some adaptation period, for example), some small band-aids are always nice if they don't hurt.

The bindings to cycle video, audio (and subtitle) tracks for example are kind of obscure. I can never remember audio. And some bindings would probably benefit from having their opposite action with a shift modified (like cycling subtitles).

[rossy]

@mvhulten The bindings are gone, but the functionality is still there, so you can restore them if you want. mpv provides a sample input.conf file that restores some of MPlayer's bindings:
https://github.com/mpv-player/mpv/blob/master/etc/mplayer-input.conf

[AirPort]

Were there important reasons to remove keys for adjusting contrast, brightness and so on?

AFAIK they were not touched in the end. You can still change contrast, brightness and so on with 1-8 keys by default, and as far as I remember those were also the exact same keys used in mplayer.

[rossy]

@AirPort Oh, you're right. I assumed they were gone because they were in mplayer-input.conf, but it looks like they're mostly still there. I guess the hue controls were replaced with gamma controls.

[mvhulten]

Thank you all for the useful comments, both on the more philosophical issue (@FichteFoll) and for the practical tip (@rossy).

@AirPort, you are right; I had the experience in the past that by default 0—8 don't do anything in mpv, but that is not the case now (mpv 0.14 on Ubuntu), so it's not an issue.

[ghost]

The bindings to cycle video, audio (and subtitle) tracks for example are kind of obscure. I can never remember audio. And some bindings would probably benefit from having their opposite action with a shift modified (like cycling subtitles).

The current state is not too bad, while changing the bindings would basically confuse every existing mpv user. But I'm still open for a redesign that makes the bindings significantly saner. But I feel like we can't just incrementally reassign individual keys over a couple of releases.

I guess the hue controls were replaced with gamma controls.

Gamma was considered more useful.

[FichteFoll]

But I feel like we can't just incrementally reassign individual keys over a couple of releases.

Indeed, that would be awful.

I believe it has to be an "everything at once" approach with the deprecation periods known by other software. As in, you add the new feature but it's disabled by default. Later (or at the same time) you add deprecation notices so that people have time to adapt. Then you change the default but have the old option still for some users until it gets completely removed at a later time.

I still like the draft by @lachs0r in the other issue a lot: #103 (comment) (with a couple minor adjustments). This could definitely be used as a base.

(Btw, am I the only one who prefers their down key to seek foward and their up key to seek backward? Same for chapters on page up/down. I mean, that's how they usually work with scrolling.)

[Tratoschek]

Another suggestion: Since page down and page up was mapped to chapters (good mapping btw), on media files without chapters there are meaningless. What about (re)map page down and page up to 10 minutes seek, but only if there are no chapters present? So they can always be used to navigate quickly in the media.

[Traneptora]

Is this still relevant at this point, or are the keybindings pretty stable as of now? I personally do not think they need to be changed at this point.

[Tratoschek]

Do you refer to my post? This change does not force the user to change old behaviour, but instead provides more functionality in some cases, so I'd say this don't break any stable behaviour, but is simply a feature.

[kevmitch]

Do you refer to my post? This change does not force the user to change old behaviour, but instead provides more functionality in some cases, so I'd say this don't break any stable behaviour, but is simply a feature.

mpv doesn't currently offer a way to make state-dependent keybindings outside of scripts. I'm not sure if it should either beyond the current toggle / cycle functionality.

[FichteFoll]

I thought that crossed my mind yesterday were key chords, where a sequence of keys could be assigned to an action much like vim bindings. I.e. zs to toggle subtitles, za to toggle audio, zd to toggle debanding. Furthermore, actions could be multiplied by pressing number keys before them, i.e. 10RIGHT would invoke the action on the right key 10 times (precompute what would happen as opposed to actually seeking 10 times).

A problem with that might be that currently the number keys are already occupied. If modal bindings existed, comparable to i3wm, they could be grouped into an "adjustments" mode or similar. Except for volume, as that needs to remain accessible.

I know this is talking big as the implementation and the required changed to key bindings are considerably significant, but this is all about brainstorming imo. mpv just has a lot of commands and binding even a subset of that to a single set of keys seems difficult.

---

Regarding the current state of key bindings: I'm not too happy with the defaults, hence why my input.conf has many bindings to tweak them to my liking. I haven't overhauled the whole thing though and only iterate on it when I need a certain binding. Imo my ideas above would help with the jungle of bindings greatly.

[garoto]

[...] where a sequence of keys could be assigned to an action much like vim bindings. I.e. zs to toggle subtitles, za to toggle audio, zd to toggle debanding.

It's also possible to bind a command to a sequence of keys:
a-b-c show-text "command run after a, b, c have been pressed"

Already a feature no?

[FichteFoll]

Indeed, it looks like it. This is great and probably something the default bindings could benefit from.

[ipatch]

Am I the only one thinking that scroll up & scroll down on a touchpad should respectively raise & lower the volume 🔈 of the playback?

And that moving from left to right on the trackpad should scrub through the playback of whatever is being played with mpv?

As it currently stands with mpv 0.28.0 scrolling up & down scrubs through the playback, and scrolling left / right adjusts the volume of the playback. ¯\(ツ)/¯

I am aware these settings can be changed in the input.conf file, but I strongly suggest my suggestions would make for a more sane 👩‍⚕️ overall default experience

Just harping 🎵 on that attention to detail thing.

[FichteFoll]

FWIW, here are my bindings:

https://github.com/FichteFoll/dotfiles/blob/master/mpv/.config/mpv/input.conf

• Cycling tracks uses a key that makes sense (i.e. a for audio, v for video, e for edition, us for subtitles) and the same key with shift to cycle backwards. (Edit: these now open uosc menus instead but serve the same purpose)
• Arrow down and page down seek forward, arrow up and page up seek backward.
• Home and end bindings.
• Volume on mouse wheel.
• I use z-* (where * is some other key) for toggling most things, including visibility of subtitles or debanding. Also for cycling some less commonly used properties like tscale.

The rest is pretty uninteresting in the general sense and just some personal preferences.

[ipatch]

@FichteFoll thanks for sharing. I saw you remapped the scroll up / down to adjust the volume 👍

However, I didn't see a scroll left / right? I don't use a mouse per se as I am on a portable 💻 so I end up using the trackpad / touchpad 99% of the time, so being able to scrub the playback using two fingers ✌🏾 to the left or to right is crucial for my situation.

Thanks again for sharing.

cheers 🍻
Chris

[FichteFoll]

I use this config primarily on my desktop, which has a standard mouse and is not capable of scrolling left and right. I could test if it works for my laptop, but I think I'd end up using the arrow keys to seek anyway.

[ipatch]

@FichteFoll

I now have my trackpad / touchpad setup to the way that seems sane 👩‍⚕️ to my liking. I ended up adding the below to my input.conf

AXIS_UP add volume 2
AXIS_DOWN add volume -2

AXIS_LEFT seek 5 exact
AXIS_RIGHT seek -5 exact

Not exactly sure why the -5 scrubs the playback forward in time 🤔 but moving my two fingers to the right progresses forward in playback, and moving my two fingers to the left scrubs the playback back in time.

[kevmitch]

There was a request over in #5466 for

y sub-step +1 # immediately display next subtitle
g sub-step -1 # immediately display previous subtitle

[ghost]

These were removed once. If they're readded, I think they should use more logical keys.

[Asinin3]

I would really like to see mouse side buttons skipping to next/previous chapters with the default bindings. Almost all other media players I've used do this by default or skip to the next file.

MOUSE_BTN8 add chapter 1 # skip to next chapter
MOUSE_BTN7 add chapter -1 # skip to previous chapter

[xantoz]

From #6361:

Consider using = instead of (or perhaps in addition to) + in some places to avoid having to shift (e.g. on standard US QWERTY layout) for +.

E.g.

ctrl++ add audio-delay 0.100           # this changes audio/video sync
ctrl+= add audio-delay 0.100           # convenience, no stretching for shift
ctrl+- add audio-delay -0.100

Alt++     add video-zoom   0.1
Alt+=     add video-zoom   0.1
Alt+-     add video-zoom  -0.1