Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup of default key bindings (second try) #973

Open
wm4 opened this issue Jul 31, 2014 · 90 comments

Comments

Projects
None yet
@wm4
Copy link
Contributor

commented Jul 31, 2014

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

This comment has been minimized.

Copy link
Member

commented Aug 1, 2014

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

This comment has been minimized.

Copy link
Member

commented Aug 1, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2014

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

This comment has been minimized.

Copy link
Member

commented Aug 1, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2014

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

This comment has been minimized.

Copy link

commented Aug 2, 2014

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.

wm4 pushed a commit that referenced this issue Aug 3, 2014

wm4
input.conf: remap 2 keys
Nobody uses 'c' (except accidentally) - remove.

Everyone agrees that OSD level cycling on 'o' is dumb, so map it to
show_progress instead. Cycling the OSD level is now available on 'O'.
No reason to ummap 'P' yet.

Also see issue #973.
@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 3, 2014

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

This comment has been minimized.

Copy link
Member

commented Aug 4, 2014

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

@lachs0r

This comment has been minimized.

Copy link
Member

commented Aug 4, 2014

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

This comment has been minimized.

Copy link

commented Aug 4, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2014

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

@Argon-

This comment has been minimized.

Copy link
Member

commented Aug 4, 2014

(I did so too)

@qmega

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2014

I also have p mapped to show_progress.

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 4, 2014

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

@bodayw

This comment has been minimized.

Copy link

commented Aug 4, 2014

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.

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 5, 2014

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

This comment has been minimized.

Copy link
Member

commented Aug 5, 2014

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 comment has been minimized.

Copy link
Contributor

commented Aug 6, 2014

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?

wm4 pushed a commit that referenced this issue Aug 7, 2014

wm4
input.conf: remap pgup/dwn to chapter seeks
As discussed in #973.

Keep the old bindings for now; there's no reason to unmap them yet.
@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2014

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.

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2014

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

@Bilalh

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2014

I also have p mapped to show_progress.

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2014

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

This comment has been minimized.

Copy link

commented Aug 8, 2014

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

This comment has been minimized.

Copy link

commented Aug 8, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2014

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

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2014

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.

@FichteFoll

This comment has been minimized.

Copy link

commented Sep 29, 2016

As others have mentioned in #103 already, having the mouse wheel seek is really annoying and I'd rather have it control volume (like in other players) or do nothing instead.

The reason being that the mpv window might be active but the mouse pointer not on-top of it. Some applications (like web browsers) will not scroll when the mouse pointer is not within their window, which makes it a safe thing to do when your mouse is over a different window. For mpv, this is not the case and hitting the mouse wheel a few times will make you seek to a different part of a video and you don't know where you initially came from.

@rossy

This comment has been minimized.

Copy link
Member

commented Sep 30, 2016

The reason being that the mpv window might be active but the mouse pointer not on-top of it. Some applications (like web browsers) will not scroll when the mouse pointer is not within their window, which makes it a safe thing to do when your mouse is over a different window. For mpv, this is not the case and hitting the mouse wheel a few times will make you seek to a different part of a video and you don't know where you initially came from.

As I said in #103, I totally agree with making the mouse wheel do nothing by default, though it's worth mentioning that this specific behaviour of scrolling the window with keyboard focus rather than the window under the mouse pointer is Windows-specific (X11 doesn't do it) and it differs between Windows versions. For a while, the Windows UX guidelines said to scroll the window under the mouse, but Windows itself dispatched scroll events to the window with keyboard focus. Web browsers and a few other big programs (like Office) have some code to reroute the scroll events back to the window under the mouse (if it's owned by them,) but smaller programs like mpv just handle all the scroll events that Windows gives them.

In Windows 10, Microsoft added a setting to dispatch scroll events to the window under the mouse for all programs (pictured below.) In the November update (I think,) they made it default, so mpv on Windows 10 no longer has this problem. We could probably fix it for Windows 7 as well by ignoring scroll events when the cursor is outside the window, but this would have the effect of disobeying the user's settings on Windows 10.

@mvhulten

This comment has been minimized.

Copy link

commented Aug 16, 2017

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

This comment has been minimized.

Copy link

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 16, 2017

@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

This comment has been minimized.

Copy link

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 16, 2017

@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

This comment has been minimized.

Copy link

commented Aug 16, 2017

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.

@wm4

This comment has been minimized.

Copy link
Contributor Author

commented Aug 16, 2017

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

This comment has been minimized.

Copy link

commented Aug 16, 2017

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

This comment has been minimized.

Copy link

commented Nov 1, 2017

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.

@thebombzen

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

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

This comment has been minimized.

Copy link

commented Dec 5, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

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

This comment has been minimized.

Copy link

commented Dec 5, 2017

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

This comment has been minimized.

Copy link

commented Dec 5, 2017

[...] 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

This comment has been minimized.

Copy link

commented Dec 5, 2017

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

@ipatch

This comment has been minimized.

Copy link

commented Jan 31, 2018

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

This comment has been minimized.

Copy link

commented Feb 1, 2018

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, u for subtitles (s is for screenshots)) and the same key with shift to cycle backwards.
  • 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

This comment has been minimized.

Copy link

commented Feb 1, 2018

@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

This comment has been minimized.

Copy link

commented Feb 1, 2018

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

This comment has been minimized.

Copy link

commented Feb 1, 2018

@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

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

There was a request over in #5466 for

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 6, 2018

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

kevmitch added a commit that referenced this issue Mar 5, 2018

input: minor additions to default key bindings
This adds key bindings for some semi-popular features. It also tries to
cleanup some old bindings. For example w/e for panscan is now changed to
w/W. In all cases, the old bindings are still kept and work, though.

Part of an ongoing attempt to cleanup the default key bindings.
See #973 for some context.

deu added a commit to deu/mpv that referenced this issue Mar 20, 2018

input: minor additions to default key bindings
This adds key bindings for some semi-popular features. It also tries to
cleanup some old bindings. For example w/e for panscan is now changed to
w/W. In all cases, the old bindings are still kept and work, though.

Part of an ongoing attempt to cleanup the default key bindings.
See mpv-player#973 for some context.
@Asinin3

This comment has been minimized.

Copy link

commented Oct 15, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.