select.lua: populate the context menu

[guidocella]

input.conf: format some commands more consistently

The formatting of input.conf commands is totally inconsistent. At least for the commands that will be used in the context menu, make it consistent. The next commit will define the context menu commands, and the keys bound to these commands will be shown in the menu only when they match exactly, so this avoids copy pasting commands with inconsistent formatting just to make them match.

menu.conf: add this file

Add a default context menu definition in etc/menu.conf. It will be used to populate the context menu.

The format is meant to be easily readable with just tabs as separators and submenus denoted by indentation. It avoids complicating the builtin input.conf like similar scripts do.

By not defining the shortcut keys in the builtin input.conf, menu entries won't be associated to wrong shortcuts when the user's input.conf changes key bindings without redefining the menu. Note that external scripts don't have this issue.

I used 3+ spaces as separators at first but then realized that since we have Windows users tabs will look better in editors with proportional fonts like notepad, though it still won't be perfectly aligned depending on the font. But I am still not sure what is better.

On a curious note, etc/menu.conf already existed in the past as mplayer used to have a menu. git log -p etc/menu.conf will show commits from 2002 to 2010.

command: add the default-menu property

This property contains the builtin etc/menu.conf, and will be used by select.lua. It is undocumented because it is for internal usage.

select.lua: populate the context menu

Make select.lua parse menu.conf, fill menu-data and open the context menu. This is done from select.lua to reuse the code to format the data and retrieve key bindings.

While the context menu is scrollable, for the playlist it is better to start from around the current entry rather than from the beginning, and since menu-data has no way to specify where to start, when there are more than 25 items playlist items this adds … entries that open the scrollable console menu when clicked.

input-bindings is parsed to show the shortcuts bound to commands. console and stats key bindings are skipped in case the context menu is opened together with those scripts. Multimedia and numpad keys are not shown to reduce clutter.

The old Context Menu section of the docs is merged in the more detailed context_menu.rst to not repeat the same information.

input.conf: add context menu bindings

Rebind right click and MENU to show the context menu. Shift+F10 is also bound because it is a standard context menu binding.

MENU is not added to restore-old-bindings.conf because it is uncommon.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-aarch64-pc-windows-msvc
• mpv-i686-w64-mingw32
• mpv-x86_64-pc-windows-msvc
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-14-arm
• mpv-macos-15-arm
• mpv-macos-15-intel
• mpv-macos-26-arm

[FrozenGalaxy]

Haven't looked at the code yet, but works fine on Windows too.

[guidocella]

I implemented the observers.

On the first time you open the context menu it parses menu.conf and registers the observers. By the next time you open the context menu menu-data will already be updated. There is no extra property observation overhead if you never open the context menu, e.g. with libmpv.

Since input-bindings is not observable it just uses the bindings from the first time you open the context menu.

For #15264 I hacked it as such: if playlist-count is > 999 when you first open the context menu it doesn't observe playlist and the menu item stops being a submenu to instead invoke script-binding select/select-playlist on click. There is no attempt to observe playlist-count changes or anything.

[Keith94]

I checked the dev builds, but the playlist and chapters entries are always grayed out even if they're present on my end. Any ideas?

[kasper93]

I checked the dev builds, but the playlist and chapters entries are always grayed out even if they're present on my end. Any ideas?

Already reported it here #16816 (comment), seems to be not working still.

[guidocella]

So it only happens on Windows?

[guidocella]

Fixed. type = submenu needed to be set for builtin submenus on Windows. It doesn't matter for context_menu.lua because it directly checks if item.submenu is set. In fact I don't understand why type is needed, when a separator boolean would have been enough.

[zhouxinghong]

Please do not force the right-click menu script into mpv, as this would disrupt users' customizable settings. We hope mpv will continue to adhere to its consistent minimalist design philosophy.

For users already accustomed to the simplicity of mpv, such a standard right-click menu is essentially meaningless.

[guidocella]

What? The context menu is already part of mpv. This just populates it, and no customization is disrupted.

mpv being simple is also a ridiculous myth. It is a bloated program with over 1000 options, dozens of VOs and AOs including toys like vo_tct, scripts, shaders, IPC, etc.

[zhouxinghong]

By default, the right mouse button is used for pause/play. However, this function is overridden when a right-click menu is added, unless you provide an alternative solution, such as moving the pause/play function to left-click.

[guidocella]

That has been rejected in #15405. Either way, keybindings are customizable.

[zhouxinghong]

Can I disable the right-click menu to retain its previous default behavior (right-click: pause/play)?

[na-na-hi]

What? The context menu is already part of mpv. This just populates it, and no customization is disrupted.

This has been rejected in #16726 (comment). Default input.conf change should be separated into its own PR.

[guidocella]

Can I disable the right-click menu to retain its previous default behavior (right-click: pause/play)?

mpv keybindings have always been customizable, and this PR already modifies etc/restore-old-bindings.conf‎ to show the previous binding. Also disabling features and changing keybindings are different things.

What? The context menu is already part of mpv. This just populates it, and no customization is disrupted.

This has been rejected in #16726 (comment). Default input.conf change should be separated into its own PR.

That was about the ASS menu? That has already been merged,

[na-na-hi]

That was about the ASS menu? That has already been merged,

It was merged after the default keybind change was rejected and dropped. Same applies to this.

[guidocella]

It was split because the patch to populate the menu was too big. The keybinding change is tiny in comparison.

[na-na-hi]

The keybinding change is tiny in comparison.

Do you really need me to spell them out to you?

input.conf changes are just cosmetic and don't make sense on their own.

Unless you want this never to be merged, bundling controversial changes, like right click changes will bikesheed this PR to death. Right click is already bond to play/pause. Default menu definition is orthogonal from any input changes. Bundling unrelated changes only makes PR harder to review and approve.

[ghost]

The keybinding change is tiny in comparison.

This is a bit of an underestimation. Changes to commonly used keybindings have been historically unpopular.

#12290
#12329

Edit: I have no strong opinions either way, just pointing out that intrusive changes like this have previously caused a massive upset, especially when it concerns the mouse-only operation of the player.

[guidocella]

The cosmetic input.conf changes referred to the first commit that changes the formatting of existing bindings.

Anyway, I can split the PR again but we will no longer recieve feedback from regular users like Keith94 above trying out the Windows build, and we haven't received a single feedback about the context menu definition so it would make it even less likely to receive feedback.

And it just delays the inevitable, or do you really not want to bind the context menu to right click which is just the standard in every program?

I also wouldn't take the Chinese guy seriously since in tomasklaen/uosc#1175 he was saying the right-click menu is a very good improvement...

[verygoodlee]

windows native context menu needs to escape the & character.
https://github.com/tsl0922/mpv-menu-plugin/blob/ce1f5c812dfbd9fc4db2280ee97edd6814a6ae4c/src/lua/dyn_menu.lua#L136-L138

if not escaped, URLs like https://example.com?foo=1&bar=2 in the playlist will not show the & character.

[guidocella]

That should be done in video/out/win32/menu.c then.

[verygoodlee]

That should be done in then.video/out/win32/menu.c

Yes, different menu implementations should handle their own text escaping

[verygoodlee]

Since menu-data is filled by select.lua, we should reconsider whether subprocesses should be executed asynchronously #15936 (comment)

synchronized execution will block the script thread, which means that menu-data cannot be updated during the execution of subprocess, and even the select/context-menu key binding cannot open context menu.