context_menu.lua: add this script #16726

guidocella · 2025-08-25T09:43:24Z

This implements a ASS context menu to be used on platforms other than Windows.

The select script message will allow selecting an item with a single click when releasing a mouse button, like in native context menus. This is mainly useful to cycle pause with one click.

kasper93 · 2025-08-25T15:29:07Z

Could you separate implementation of context menu to separate PR from the definition of default menu. Also there are unrelated changes sprinkled in input.conf for example, which should also be put in another PR or at least another commit. To make it easier to review and discuss.

guidocella · 2025-08-25T15:40:43Z

Are you sure? I did not separate them because it makes it much easier to test the context menu with real-world menu entries, else you have to write a script to populate it yourself, handling all possible cases like disabled items, checkboxes, hidden items, nested submenus, disabled submenus, which is what I had to do before updating select.lua.

input.conf changes are just cosmetic and don't make sense on their own. As written in the commit message they are meant to have the exact same commands in menu.conf which shows the key in the menu. But I guess I can add another commit.

kasper93 · 2025-08-25T15:51:22Z

Are you sure? I did not separate them because it makes it much easier to test the context menu with real-world menu entries, else you have to write a script to populate it yourself, handling all possible cases like disabled items, checkboxes, hidden items, nested submenus, disabled submenus, which is what I had to do before updating select.lua.

Yes. Unless you want this never to be merged, bundling controversial changes, like default menu definition and right click changes will bikesheed this PR to death. We already have working context menu on windows and various scripts to populate it. Implementing context menu in ass is orthogonal from any default menu definition or input changes.

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

Bundling unrelated changes only makes PR harder to review and approve. I don't want to police git usage, but if you drop +1,427 −55 in two commits, with random changes bundled in it is just making things harder.

github-actions · 2025-08-25T16:30:51Z

Download the artifacts for this pull request:

Windows

macOS

hooke007 · 2025-08-26T01:07:03Z

DOCS/man/options.rst

+``--load-context-menu=<yes|no>``
+    Enable the builtin script that implements a context menu. Defaults to
+    ``yes`` on platforms where integration with a native context menu is not
+    implemented, and to ``no`` on platform where it is.


Should it be auto instead? I am not sure if some would prefer the OSD menu than GUI menu.

What do you mean? It already behaves like auto by changing default value based on the platform.

It's not the explicit value auto. Is there any reason to make the option special?

The reason is that the default value can be determined at compile time unlike every other auto option, removing the need to implement a context-menu-loaded property.

If it wouldn't be conflict with GUI menu. I think I will always set it to yes to use two menus together in different cases.

I have no idea what you mean by GUI menu.

Do you mean Windows users cannot use the ASS menu?

--load-context-menu defaults to no on Windows so that select.lua will prefer opening the native context menu, but nothing stops you from ignoring this option and opening either menu in a third party script.

By the way, the only advantage of the native context menu I see is that it can be drawn outside of mpv's window. Whereas the advantage of the ASS menu is that you can customize its appearance.

kasper93 · 2025-08-26T08:45:03Z

When the list of items doesn't fit on screen it should be scrollable.
Text is pretty huge and even few tracks doesn't fit, not to mention files with 20+ tracks or chapters
Could overlap few small portion of sub menu to make it show that it's stacked
Left and right text (shortcut for example) need better (wider) separation [1] looks like "Play Space", there is not enough visual separation between them
Right click shouldn't activate item, only left
When mouse is outside mpv window menu will show up snapped to the left side, but vertically it remembers last mouse position, when it left window. Should be consistent and pick one "no mouse" location
It's bit laggy and slow to navigate, this may not be easy to resolve given it's ASS. But it should clear previous highlight when moving to next element first. Currently you can have two items highlighted, which likely happens, because of the order in which things are drawn. This needs to be revised to hide as much issues as possible.
It should be DPI scaled, similar to system menu. It's lots of text that hae to be readable also form far away. This will also resolve text size situation, because currently as I understand is made huge, because of lack of DPI scaling.

[1]

kasper93 · 2025-08-26T08:49:50Z

options/options.c

    .lua_load_select = true,
    .lua_load_positioning = true,
    .lua_load_commands = true,
+#ifndef _WIN32


This looks iffy. What about macOS, or other possible implementations of context menu?

What is iffy? When the macOS context menu is implemented this needs to be updated to #if !defined(_WIN32) && !defined(HAVE_COCOA)

When the macOS context menu is implemented

macOS has its own context menu implemented already.

Implementing the macOS context menu is literally listed as a goal in #13608. Only the top bar menu is implemented.

What is the goal of disabling context menu script anyway? It's not bound to any key, so there is no conflict.

It just reduces the number of threads running.

guidocella · 2025-08-26T10:10:18Z

When the list of items doesn't fit on screen it should be scrollable.

I thought the native Windows context menu is not scrollable (I asked whether it is on IRC 4 months ago but no one replied) hence why https://github.com/tsl0922/mpv-menu-plugin implements max_playlist_items. So that would make many menu entries work only half the time when not using the native menu, other than implementing a second scrollable menu being a lot of work. The next commit would handle many menu entries like mpv-menu-plugin by adding … menu entries that open the scrollable console menu.

Text is pretty huge and even few tracks doesn't fit, not to mention files with 20+ tracks or chapters

28 items fit for me with window scaling ¯\(ツ)/¯. I just picked default sizes that look good to me, I'm sure everyone will have different preferences. I will update them to whatever you prefer.

Could overlap few small portion of sub menu to make it show that it's stacked

I made 5 pixels overlap but it looks cluttered to me. GTK/Qt/tk menus don't do this.

Left and right text (shortcut for example) need better (wider) separation [1] looks like "Play Space", there is not enough visual separation between them

They are more distant in real-world menus because the shortcuts are right aligned and you will have longer texts than "Play". The GTK menu has similar distance from the longest entry. Still I increased the minimum spaces from 2 to 4.

Right click shouldn't activate item, only left

All native context menus activate items on right click?

When mouse is outside mpv window menu will show up snapped to the left side, but vertically it remembers last mouse position, when it left window. Should be consistent and pick one "no mouse" location

Made it start at osd_w / 4, osd_h / 8.

It's bit laggy and slow to navigate, this may not be easy to resolve given it's ASS. But it should clear previous highlight when moving to next element first. Currently you can have two items highlighted, which likely happens, because of the order in which things are drawn. This needs to be revised to hide as much issues as possible.

I assume you are referring to open submenus. They stay open until seconds_to_close_submenus expires, but the focused color can indeed be removed immediately so I updated it as such.

It should be DPI scaled, similar to system menu. It's lots of text that hae to be readable also form far away. This will also resolve text size situation, because currently as I understand is made huge, because of lack of DPI scaling.

It is DPI scaled with --osd-scale-by-window=no, like console.

verygoodlee · 2025-08-26T14:59:55Z

When mouse is outside mpv window menu will show up snapped to the left side, but vertically it remembers last mouse position, when it left window. Should be consistent and pick one "no mouse" location

Agree.
May be out of topic , currently the win32 native context menu can't open via keyboard if mouse is outside mpv window, this behavior is obviously incorrect.

The behavior of most applications is as follows:
If right-click down inside the window, move mouse outside the window and then release it up, the context menu will not pop up.
If press the shortcut key Shift+F10, the context menu will pop up regardless of whether the mouse is in the window.

kasper93 · 2025-08-27T04:53:19Z

When the list of items doesn't fit on screen it should be scrollable.

I thought the native Windows context menu is not scrollable (I asked whether it is on IRC 4 months ago but no one replied) hence why https://github.com/tsl0922/mpv-menu-plugin implements max_playlist_items. So that would make many menu entries work only half the time when not using the native menu, other than implementing a second scrollable menu being a lot of work. The next commit would handle many menu entries like mpv-menu-plugin by adding … menu entries that open the scrollable console menu.

Context menu is scrollable. Especially useful when navigating with mouse. However that size of system context menu is generally not so big, so the capacity before you need to scroll is way bigger. To reproduce the size of mpv's menu I needed to set 350% scaling.

Text is pretty huge and even few tracks doesn't fit, not to mention files with 20+ tracks or chapters

28 items fit for me with window scaling ¯_(ツ)_/¯. I just picked default sizes that look good to me, I'm sure everyone will have different preferences. I will update them to whatever you prefer.

I would match system menu sizes, which is also why I suggested to DPI scale it. Unlike OSC, context menu feels like something separate.

Could overlap few small portion of sub menu to make it show that it's stacked

I made 5 pixels overlap but it looks cluttered to me. GTK/Qt/tk menus don't do this.

Something to discuss. We could not do that, I think at least on Windows there is small drop shadow that makes it look stacked one on top of another.

Left and right text (shortcut for example) need better (wider) separation [1] looks like "Play Space", there is not enough visual separation between them

They are more distant in real-world menus because the shortcuts are right aligned and you will have longer texts than "Play". The GTK menu has similar distance from the longest entry. Still I increased the minimum spaces from 2 to 4.

Should this be 1 or 2 tabs, instead of spaces?

Right click shouldn't activate item, only left

All native context menus activate items on right click?

They don't on Windows. I think it's not a big deal, just something that don't have much use probably.

When mouse is outside mpv window menu will show up snapped to the left side, but vertically it remembers last mouse position, when it left window. Should be consistent and pick one "no mouse" location

Made it start at osd_w / 4, osd_h / 8.

I would put it just ad top left (0, 0) to maximize available space

It's bit laggy and slow to navigate, this may not be easy to resolve given it's ASS. But it should clear previous highlight when moving to next element first. Currently you can have two items highlighted, which likely happens, because of the order in which things are drawn. This needs to be revised to hide as much issues as possible.

I assume you are referring to open submenus. They stay open until seconds_to_close_submenus expires, but the focused color can indeed be removed immediately so I updated it as such.

No, I meant that moving mouse over items first highlight new item and after delay unhighlight previous item. I can't repro it now,

It should be DPI scaled, similar to system menu. It's lots of text that hae to be readable also form far away. This will also resolve text size situation, because currently as I understand is made huge, because of lack of DPI scaling.

It is DPI scaled with --osd-scale-by-window=no, like console.

See my size response.

guidocella · 2025-08-27T05:37:06Z

Context menu is scrollable. Especially useful when navigating with mouse. However that size of system context menu is generally not so big, so the capacity before you need to scroll is way bigger. To reproduce the size of mpv's menu I needed to set 350% scaling.

Why in hell does mpv-menu-plugin cut playlist items then?

I would match system menu sizes, which is also why I suggested to DPI scale it. Unlike OSC, context menu feels like something separate.

Do you want do remove window scaling then? It was disabled in console because scaling both with the window and DPI made text too big.

Something to discuss. We could not do that, I think at least on Windows there is small drop shadow that makes it look stacked one on top of another.

This has a shadow too if you set --osd-shadow-offset. I use it and menus look better with it. I removed the overlap for now.

Should this be 1 or 2 tabs, instead of spaces?

\t\t is smaller than 4 spaces. I am not aware of a difference otherwise.

They don't on Windows. I think it's not a big deal, just something that don't have much use probably.

Seems to be the oddball. Anway I don't know about pressing down right click but activating when releasing right click is quite useful to activate the first item in 1 click, e.g. to go back in browser.

I would put it just ad top left (0, 0) to maximize available space

I think it looks better with more centering but done.

No, I meant that moving mouse over items first highlight new item and after delay unhighlight previous item. I can't repro it now,

I've never seen that other than with the open submenus I just modified.

kasper93 · 2025-08-27T05:42:51Z

Context menu is scrollable. Especially useful when navigating with mouse. However that size of system context menu is generally not so big, so the capacity before you need to scroll is way bigger. To reproduce the size of mpv's menu I needed to set 350% scaling.

Why in hell does mpv-menu-plugin cut playlist items then?

It's probably still nicer to limit the size, instead of filling whole screen with huge list.

I would match system menu sizes, which is also why I suggested to DPI scale it. Unlike OSC, context menu feels like something separate.

Do you want do remove window scaling then? It was disabled in console because scaling both with the window and DPI made text too big.

Not sure what's best, if we want to mimic system context menu like or more something inside of mpv. I would disable window scaling and enable dpi scaling instead and see where it gets us.

guidocella · 2025-08-27T05:49:02Z

The problem is that we can't emulate the system menu that well because it can't render outside of the window. So the context menu in a small window will barely fit any items without scaling with the window, whereas the system one can just render outside of mpv's window at full size.

kasper93 · 2025-08-27T06:29:37Z

The problem is that we can't emulate the system menu that well because it can't render outside of the window. So the context menu in a small window will barely fit any items without scaling with the window, whereas the system one can just render outside of mpv's window at full size.

As discussed on IRC, it can be scaled with window as is.

guidocella · 2025-08-27T11:50:57Z

Implemented scrolling only of 1 page at a time as you suggested.

This implements a ASS context menu to be used on platforms other than Windows. The select script message will allow selecting an item with a single click when releasing a mouse button, like in native context menus. This is mainly useful to cycle pause with one click.

garoto · 2025-08-29T16:37:06Z

All native context menus activate items on right click?

They don't on Windows. I think it's not a big deal, just something that don't have much use probably.

Just wanted to point it out that menu entries do activate with right-mouse click on my current Windows10 box as it does on my windows 8.1 one, and yes I'm talking native Windows context-menus, like right-clicking the taskbar and right-clicking any option. Pretty sure that is the case for the longest time.

kasper93 · 2025-08-29T17:10:09Z

All native context menus activate items on right click?

They don't on Windows. I think it's not a big deal, just something that don't have much use probably.

Just wanted to point it out that menu entries do activate with right-mouse click on my current Windows10 box as it does on my windows 8.1 one, and yes I'm talking native Windows context-menus, like right-clicking the taskbar and right-clicking any option. Pretty sure that is the case for the longest time.

It does not it current mpv context menu.

garoto · 2025-08-29T17:40:46Z

It does not it current mpv context menu.

Ah ok, thought you're talking about Windows menus in general.

kasper93

Should be fine, we can iterate on this, thanks.

guidocella force-pushed the menu branch from d5e8602 to 3da8a96 Compare August 25, 2025 09:49

guidocella force-pushed the menu branch from 3da8a96 to 0867820 Compare August 25, 2025 15:46

guidocella force-pushed the menu branch 2 times, most recently from 50a078d to db4aa80 Compare August 25, 2025 16:13

hooke007 reviewed Aug 26, 2025

View reviewed changes

kasper93 reviewed Aug 26, 2025

View reviewed changes

guidocella force-pushed the menu branch from db4aa80 to 06de1c1 Compare August 26, 2025 10:10

guidocella force-pushed the menu branch from 06de1c1 to d31af4e Compare August 27, 2025 05:35

guidocella force-pushed the menu branch from d31af4e to 61b881b Compare August 27, 2025 05:37

guidocella force-pushed the menu branch from 61b881b to b74d18f Compare August 27, 2025 11:49

guidocella force-pushed the menu branch 4 times, most recently from 6eafd98 to e64cdbc Compare August 28, 2025 08:39

guidocella force-pushed the menu branch from e64cdbc to d36e368 Compare August 28, 2025 09:25

kasper93 approved these changes Sep 15, 2025

View reviewed changes

kasper93 merged commit 8406834 into mpv-player:master Sep 15, 2025
29 checks passed

na-na-hi mentioned this pull request Nov 21, 2025

select.lua: populate the context menu #16816

Open

context_menu.lua: add this script #16726

context_menu.lua: add this script #16726

Uh oh!

Conversation

guidocella commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Aug 25, 2025

Uh oh!

guidocella commented Aug 25, 2025

Uh oh!

kasper93 commented Aug 25, 2025

Uh oh!

github-actions bot commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hooke007 Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

guidocella Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kasper93 commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

guidocella Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

guidocella commented Aug 26, 2025

Uh oh!

verygoodlee commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Aug 27, 2025

Uh oh!

guidocella commented Aug 27, 2025

Uh oh!

kasper93 commented Aug 27, 2025

Uh oh!

guidocella commented Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Aug 27, 2025

Uh oh!

guidocella commented Aug 27, 2025

Uh oh!

garoto commented Aug 29, 2025

Uh oh!

kasper93 commented Aug 29, 2025

Uh oh!

garoto commented Aug 29, 2025

guidocella commented Aug 25, 2025 •

edited

Loading

github-actions bot commented Aug 25, 2025 •

edited

Loading

hooke007 Aug 26, 2025 •

edited

Loading

guidocella Aug 26, 2025 •

edited

Loading

kasper93 commented Aug 26, 2025 •

edited

Loading

guidocella Aug 26, 2025 •

edited

Loading

verygoodlee commented Aug 26, 2025 •

edited

Loading

guidocella commented Aug 27, 2025 •

edited

Loading