input.conf: bind right click to context menu#18057
Conversation
There was a problem hiding this comment.
mpv's lack of a (easily findable) context menu
So check this out, I'm literally a developer and I didn't even know this specific menu existed. I don't use select.lua much and occasionally used the other menu for debugging purposes but I had no idea there was a right click menu like VLC.
Takes two clicks to pause instead of one but I think the tradeoff is worth it (also just press spacebar).
Edit: This should have an entry under DOCS/interface-changes though.
Degrading usability for one of the most common features is unacceptable. If you really want this at least also bind left click to pause.
The "developer" badge means nothing here, because not all of them track all PRs. Like @sfan5 who had complained several times with "surprise" changes like this before. Re VLC: #16816 (comment)
And |
arch1t3cht
force-pushed
the
right-click-context-menu
branch
from
44ff00d to
e2a391e
Compare
Right click for a context menu is consistent with just about every program (video player or not) I can think of. This is not just about VLC, this also applies to most of Windows's built-in players (Windows media player and the new "Media Player"), browser video players, etc. Left click to pause, on the other hand, is not standard across all programs (it's not the default in VLC, Films & TV, Windows Media Player, or QuickTime player), and there are good reasons why you would want it to not be enabled. But right click to open a context menu is not even a question of usability, it's a question of discoverability and first-time user experience. I will probably remap right click to pause on all my devices when this is merged, because I personally am used to it and am familiar with mpv's features. But I still think that for a first-time user, right click for a context menu is the infinitely better experience.
I checked other changes to hotkeys and none of them had entries for DOCS/interface-changes, but I can add one if it's really needed.
There already is one. I rebased to fix the CI now, though. |
Where did I say that the right click for a context menu is bad? Please stop with your strawman. The whole point is that replacing right click with another action, no matter what that is, means that one click pausing is no longer available.
It is used by MPC-HC, Chromium (which is used by countless electrom programs and webapps), and Firefox. The web browsers alone make this behavior much more popular than not available.
And yet you removed one click pausing, which is the expected behavior for arguably the most popular program (major web browsers) on the planet.
Which are? |
|
👎 from my side As a keyboard-first media player mpv has an unique control scheme and I think we don't need to converge on the "average media player". |
I thought that's what you meant by "Degrading usability for one of the most common features is unacceptable.", sorry if that wasn't the case.
Various reasons were discussed in #15405 but as a summary:
I do understand the argument that removing "right click to pause" makes it harder to play/pause with one click. But users can still play/pause a) Using the space bar Personally, with this in mind I think that it's better to leave left click unbound than having it play/pause, but this is not a hill I'm intending to die on. If the majority prefers "Left click to play/pause, right click for context menu", I'd be fine with that. My main priority is making the context menu more easily accessible.
I elaborated on this above, but let me reiterate that I don't care about matching the "average media player", I care about discoverability for new users. This change matches other media players not for the sake of matching them, but because it's good UX and other media players also happen to have good UX (at least in that regard). |
This is the first thing I unbound in MPC-HC. Especially in borderless layouts it is problematic to bring player to front, it's problematic to toggle fullscreen with double click without pausing playback. Accidental touches pause. If you decide to drag window, but change your mind after clicking, it will pause... and so on. You can read more discussion on this topic here #15405 This could be solved, if OSC would provide configurable clickable virtual zones. Where middle area would pause, while sides would allow you to click to drag/focus. This however, is blocker for left click, not the context menu.
Feel free to use keyboard interface, nothing changes here. Also, I don't see this as converging on the "average media player". The context menu is genuinely the only interface that makes mpv usable with mouse-only controls. OSC is basic, not extensible and doesn't provide easy access to operations. And this is good, because OSC shouldn't be cluttered mess of controls and clickable buttons. Context menu is familiar interface, used ubiquitously in any software, ranging from "average media player" to highly specialized professional tools. There is nothing "average" about it. P.S. Even most tech-savvy users, may not want to spend hours to maintain and learn keyboard spells to do basic operation on media player of all things. While it's perfect interface for others. |
It's a big enough change that it's worth mentioning in release notes imo. |
|
How about we bind pause to mid mouse button? I understand the hesitance to change any of this in the first place. I wouldn't want to do that either. But I genuinely think that binding context menu to right mouse button is actually the pragmatic and important change to do. For people who care it's trivial to rebind the key. For new users this is huge accessibility improvement. We need to bite the bullet here. I know it sucks, but I don't think this PR is question "if" we do that, but how we did the things around this. |
Alright, done. |
arch1t3cht
force-pushed
the
right-click-context-menu
branch
from
e2a391e to
7ca4450
Compare
While these are valid points and ideally they should be avoided, the question here is whether avoiding misclicking justifies removing one click pause, in the context that right click is no longer available. IMO it's not: misclicks are less frequent than intended clicks, and the misclicks are very easily corrected with just another mouse click, without needing to move the mouse and aim at some UI element at all. The major web browsers have decided that having both single left click to pause and double left click to toggle fullscreen at the same time is OK. The annoyance is small compared to the convenience it provides.
Keyboard isn't always easily accessible. Not touch friendly.
Needs to move the mouse to aim at the small button first, making it inferior UX according to Fitz's law. This is very inconvenient especially at windowed mode. Not touch friendly.
Takes more clicks. And
Mid mouse button is occupied by pasting while the console is open. |
I consider binding LMB to pause a far more invasive change. Left click is one of the most commonly used buttons in any interface. Binding it to pause now would affect everyone who clicks on the mpv window for any reason. Instead of a single change, moving I agree that one-click-pause is important. I myself was using it all the time, and when migrated to use context menu for track selection, bound middle mouse button to rectify this. This works for me, and was very quick to adjust. It mitigates all the issues with LMB, while preserving one-click-pause with mouse only usage. Though now I would bind it to mouse4 probably, because it is even more convinient, if you have such button. Think about the groups of people each change affects. Users who pause with right click can adapt by simply clicking again the pause item instead. That's a change, but we have to free up the right mouse button for the context menu somehow. What you're proposing affects all left clicks as well, in a way that may not be expected. This change isn't meant to force users onto different defaults, it's about discoverability of the context menu. Putting it on a common button makes it accessible. If I open any piece of software, right-click, and there's no context menu, it would never occur to me that I need to enable or bind it myself. That's just not how it's done. This isn't about mpv being an "average" media player, it's about following basic UX expectations.
This is a very different case. As I mentioned, the whole browser window doesn't pause on click. Only the video area does. You have plenty of other elements you can click or drag to bring the window to the front, and so on. In mpv with I'm not saying binding left mouse button to pause is a bad idea. It just introduces annoyances that anyone would notice immediately. Arguably for touch controls, the click to pause could be useful, but that's not currently done either, so there is no precedence. Right clicking on touch interfaces is not something anyone does too.
When the console is open, keyboard bindings don't work either. There's nothing to optimize here, we can ignore this 0.000001% corner case for once and not move the bar. You can click twice if you really want to in that case. To summary, I actually don't mind this much the LMB to pause, if this is required change. But it actually seems more controversial, than enabling context menu by itself. And again this is about discoverability, not forcing random changes on users. There will be always affected users, but if we desire to have no changes, we should actually do any changes and just abandon the project... I don't think we will get anywhere with this discussion. There will always be someone unhappy, but if it is 10/90 split, than we have to make compromise. We cannot block any change, because there is one guy who is not happy about it. I recognize one-click pause is something that people want. Also I think binding other mouse button (like 4) to pause, is way more convenient, because you don't actually need to click on the window. Anyway, I started drifting way to far already. My only concern about LMB is that I don't want to introduce annoyances to mpv, that's why I propose other mouse button. Also this: |
|
I don't think we should bind left or middle mouse buttons to pause. And if that is what is required to merge this PR, then I oppose it. This is a "compromise" where absolutely no one is happy. Simply changing RMB to context menu is an acceptable and good change. Remember, mpv is a keyboard player and spacebar is used to pause. RMB to mouse exists for people who want to use mpv with mouse-only, and context menu for RMB is an objective improvement for that use case. |
|
Binding LMB to pause is pretty clearly a much bigger and more invasive change than this proposal (and one I would certainly oppose). Personally not a fan binding the middle mouse either. |
|
It clear that binding and selecting the (new) key for |
Putting it on right mouse button changes defaults, and the intention means nothing when the end result is the same. Like if you add a new flag for
Two finger tap or tap-and-hold translate to right mouse click.
My request isn't meant to force LMB to pause a required change, it's about keeping the one click pause functionality. How this is achieved is left to be figured out by the PR author.
There are other ways to improve discoverability without changing right mouse button. It can replace the menu button on OSC, it can show as a hamburger menu at top left corner that shows up with OSC, etc. But if you want to use RMB for this, the one click pause discussion stays.
So you mean that RMB isn't for people who use mpv with keyboard? Do you think anyone with a keyboard must pause with space otherwise they are holding mpv the wrong way? |
|
I think all the relevant arguments for both sides have been repeated multiple times by now. The only thing I can add is a meta-summary of the discussion:
From what I've seen, I don't think anybody here disagrees that Problem A exists or that Problem B would be introduced. At most, the points of disagreement are how significant Problems A and B each are, and on the general philosophy of whether it is acceptable to introduce a small problem while addressing a bigger problem. My personal opinion is that:
To word it a bit more concretely: Imagine somebody proposing to replace VLC's right click context menu with pause/play. (And, I guess, imagine that VLC did not have its menu bar.) Would anybody agree with this change? If the answer is no, then the only reason for opposition to this pull request must be the fact that it's a change, rather than its outcome. And I believe that the outcome takes priority over the change itself here. (Judging by the reactions to this PR, most people seem to agree with its proposed change.) |
|
for the issue of left-click to focus window triggers cycle pause, I have a solution through conditional auto profiles, but it's not suitable as the default config because according to the documentation, the "focused" property may not be supported by all VOs, and mpv may compile without Lua. [on-focus]
profile-cond=focused
input-commands-clr
input-commands-append=define-section left-pause "MBTN_LEFT cycle pause"
input-commands-append=enable-section left-pause allow-hide-cursor+allow-vo-dragging
input-commands-append=no-osd change-list input-commands clr ""
[on-unfocus]
profile-cond=not focused
input-commands-clr
input-commands-append=disable-section left-pause
input-commands-append=no-osd change-list input-commands clr "" |
|
|
I think I didn't explain what I meant well: While I use mpv mostly with keyboard shortcuts, it's very convenient to be able to pause mpv with just a right-click (even if not focused), because the window is an easy target to hit with the mouse. Alternatives I see that preserve easy pausing:
I agree that this isn't convenient. |
Pause is the first item on the context menu, and double clicking RMB would still lead to pausing (assuming your cursor doesn't move too much between the clicks). Admittedly, that would be a bit janky if the context menu appears on the bottom (so the cursor isn't at pause), so binding |
This doesn't work (regardless of moving the cursor or not) and just closes the context menu again. The top of the context menu has a margin before the first item. |
|
You don't to double click with the ASS menu. You can hold right click down, move the cursor right and down and release right click to pause. I intentionally emulated this feature of native context menus (except Windows ones apparently). |
|
Shift+RMB is available too, that could be used to either bring up the context menu or pause/resume in the case the context menu takes the unmodified RMB instead. This is less weird than binding the middle button to either option, and less disruptive than changing the behaviour of LMB. |
Unlike corporate projects which make lots of changes to attract new users for potential ROI even when that degrades experience for existing users up to their threshold of tolerance, community projects have no such pressure and can focus on existing users, who by definition have gotten familiar with the existing usage pattern, even when these pattern seem nonsensical in isolation.
And yet when solutions that solve both Problem A and B are proposed, the same "bikeshedding" is used again to show how bad the solutions are because they change existing behavior. For example:
while this PR also "introduces annoyances that anyone would notice immediately" for anyone who frequently use RMB to pause, which I think are very common, see my above point about existing users. I don't agree that Problem B is less invasive: pausing is definitely a more commonly used feature than context menu, so a change for that brings annoyance to more existing users than those who benefit from context menu.
mpv is not VLC. mpv is not born in the "Problem B World". mpv users have different preferences from VLC users. Applying VLC's situation to mpv directly without addressing this fact (not to mention it's in a purely imagined situation where VLC did not have its menu bar, which changes the importance of right click menu) is not a good rationale. I can use the same rationale too: Imagine somebody proposing to remove MPC-HC's left click pause/play... Of course many existing MPC-HC users will disagree with this change, even though the end result is the same. |
This doesn't follow principle of least astonishment (POLA), context menu is RMB, there is not much discussion about it. There is also third option to bind, MMB for pause, which solves all your concern, focusing window is easy, and pausing unfocused window is also easy.
I do think you overestimate the "inconvenience" of this. I use context menu, and indeed it was a noticeable change... for like 5 minutes, after which time I started using the play/pause menu. I even have MMB bound to pause, but at thins point I already forgot about it. It's very similar to how Firefox does "back" button in context menu, they are easily accessible and even if there is dedicated mouse button, many users are using context menu for this. I can assure after few tries you would even forget that RMB was pausing playback before.
This is not relevant. We are talking about mouse only input. If you have keyboard, just hit
Like you said, we are not corporate project, so please don't inject corporate bubble into this issue. But if you need, look at the KPI of this PR, it's overwhelmingly supported by existing users.
I do agree with that. However, I do also think that we overestimate the ability of users to adapt to a change.
I proposed MMB for pause and fully support it. LMB is not better solution with the amount of annoyances it will bring. It's not "bikeshedding", you can search mpc-hc issue tracker, how much complaints there is about LMB pause. Not about the pause itself, which is fine, but about the side-effects it causes, with double click fullscreen toggle, focusing window in borderless mode and so on. (also mpc-hc doesn't have working demuxer cache, so pause of network streams are quite painful)
"I don't agree"... and we can play this game. Current feedback we have from the users is overwhelmingly positive. I do agree that That's why I propose MMB for pause. Because it directly mirrors existing usecases, just with one button over. Unfortunately binding context menu to anything else than RMB, is violation of principle of least astonishment and what any software do in practice. I'd prefer LMB be left unbound to not disrupt window operations that are primary done with LMB. That says, are there any concerns about MMB use? Except console.lua (which already rebinds all keys anyway), there was no real feedback, and everyone seemingly ignore this proposal without any feedback.
VLC example is used to anchor the problem. Stop focusing on it so much.
No one propose that, because LMB for pause is good. But there were lots of discussions around this, because it causes issues, like mentioned before. |
okay, so while writing the following paragraph, i was informed that the "menu" i was thinking of is not the "context menu" being discussed, and i have in fact never seen the context menu before (it is accessible by: right-clicking on the window decoration (which i disable with
i wouldn't recommend this as a default. not all input devices even support this input (or, at least, it is not an intuitive one)—i'm not aware how you would input MMB on a trackpad, for instance. (some googling tells me that it may be any of ctrl-tap, three-finger-tap, a dedicated button below the trackpad. even then, i would have never intuitively thought of three-finger tapping the mpv window to toggle pause.) to me, it feels like a better idea to not have a dedicated "default" button on the mouse for pausing, as this would suggest to me it is "preferable" (from mpv's side) to use that, than doing so via the context menu, or e.g. focusing the window and pressing space. myself, i feel like i would also probably change back to the RMB-to-pause bind purely for my muscle memory, but most likely keep the context menu available via shift+RMB or similar. regardless, i'd still using MMB to pause feels a bit too finicky to me; M4/M5 are right out as i use those for chapter seeking. in my mind, RMB is the only bind that makes sense for this feature as a default, and the minor friction mouse-only users would get is massively outshadowed by the benefit of finally actually being able to control their player without the keyboard. "what do we move mouse-pause to" is, in my view, outside the scope of discussion here. |
I'm not "many users" then. I use mouse buttons for back/forward navigation in Firefox and in the rare case that I have a mouse without these buttons I quickly feel stupid after pressing on solid plastic.
A problem I can think of is that laptop touchpads often don't expose MMB as a separate button. |
L+R press is not middle? Anyway, I would agree to leave this for the user to decide what works best in their workflow. That's why I think current state of the PR is good to merge. |
|
It should also be reiterated again that this is purely a discussion about defaults. Any user that wants left or right click to pause/play can configure this in their input.conf with a one-line change. But, as we've seen from multiple commenters in this thread (Dudemanguy, petzku, as well as myself until recently), a user that does not know that the context menu even exists has no chance of binding it to right click. (You can argue that the average user will probably also not realize that keybinds can be configured, but this is not a black and white scale. There are multiple people in this thread that knew that keybinds could be configured and would have been able to bind right click to pause, but would not have known that the context menu existed.) That is why I weigh discoverability so strongly here. |
So why isn't this rationale also applied to this PR? Whether you agree or disagree with this rationale it has to be applied to both equally.
I showed that the rationale used to anchor the problem was flawed because when used with MPC-HC example it gave the opposite result.
Discoverability doesn't have to be RMB here. It's not like mpv has any position dependent "context" anyway when the whole window is video, and this "context menu" might as well be a "utility" menu. I have already said this before and no one commented on it:
|
I'm afraid there's a misunderstanding here. Are you aware which menu we're talking about? It's a mouse position aware floating menu that can be activated from any position in the player. That's why it has to be activated by the mouse button. Otherwise it's not doing its job if you have to aim for some "button". Side note: we already have a "hamburger menu", which is mostly designed for keyboard input, as opposed to the "context menu", which is designed for mouse input. |
Yes, I am fully aware. And what is the reason that this cannot be a hamburger menu? If the whole point is about discoverability, we can replace the existing hamburger menu or add a new one and it will achieve the same goal. There is no "context" in mpv so this "context" menu designation is arbitrary.
Yet this "hamburger menu" designed for keyboard input has a dedicated UI element space in OSC, yet the "context menu" designed for mouse input doesn't have any. Wouldn't it make more sense that the "hamburger menu" in OSC opens the menu designed for mouse input, while the menu designed for keyboard input is bound to a key instead? |
Can we not reinvent the wheel? Context menu are popup menus that are close to your mouse pointer. That's true that currently mpv has single context, but it shows a menu that is quick to access, without searching for button or even showing osc. You can read about context menus in general here https://en.wikipedia.org/wiki/Context_menu and what are the triggers for them and design principles. |
I'm guessing that kasper meant "underestimate" here, not "overestimate" |
10 participants
It is time. I volunteer as a sacrifice to face the inevitable fallout.
mpv's lack of a (easily findable) context menu is one of the biggest reasons why less experienced users still avoid mpv. Making right click show a context menu matches countless other programs and improves the first-time user experience by showing available actions and keybinds. Users that prefer right click to pause instead can configure this in their
input.conf. They can even use the context menu to open it!