This was a mistake. It's too situational and it's not worth complicating
the API and every mp.input client with it. It made some sense before I
implemented input.select() because you could use input.get() to input a
choice and validate it, but in general for input.get() clients it's
better to show an error with input.set_log() instead of adding new lines
to the log everytime. This is what e.g.
https://framagit.org/Midgard/mpv-subber/-/blob/master/subber.lua does.
So this is only marginally useful for REPL scripts that keep adding
lines to the log, and the only such scripts are commands.lua and my
lua-repl.lua. commands.lua never used it and I already removed it from
lua-repl.lua. Cloning all scripts in the wiki reveals that **nobody** is
using log_error(), confirming that it is safe to deprecate.
Any errors when opening the display are now logged.
The WAYLAND_DISPLAY check now also logs and applies only when probing.
This means explicitly setting a wayland `--gpu-context` will always
try to open the display instead of "helpfully" refusing (in some cases).
see also: f6f1721101
extends f3c1dcf7a1 for all lines not just
the last. This avoid unnecessary write every line and fixes a buffer
overflow for small enough images (for example 78x64).
Move PathCchRemoveFileSpec after actually getting the file size. It must
have been swapped at some point by accident.
Also use correct unit for the size.
Fixes: #17375
try to define a `[foo \ "bar"]` profile in mpv.conf, the command
to apply it in context-menu is `apply-profile foo \ "bar"`,
which is obviously incorrect, the correct command should be
`apply-profile "foo \\ \"bar\""`.
for string arguments that may contain spaces or some special
characters, we need to quote and escape them in JSON-style,
fortunately, `utils.format_json` can do this very well.
Fixes a deadlock when switching vo before a frame is displayed (e.g.
with auto profiles) where we'd end up in a state where wait_on_vo is set
to true for the first frame and then draw_frame is never called again so
its value never changes even once dmabuf-wayland is ready to advance
frame
Fixes: 468d34c9bd ("vo: allow VOs to request waiting before advancing frames")
As per Samillion's suggestion, reduce the contrast between separators
and the background to match other context menus. Using the already
defined disabled_color works for this and seems to be what GTK and Qt
do at a glance.
730062b510 fixed the problem with mouse
buttons but unfortunately we forgot to include repeated commands in the
condition. This effectively made any variant of "frame-step X seek"
unrepeatable even though it was supposed to be. So just allow those in
add_step_frame too.
Fixes#17348.
The playlist submenu does not update in this edge case:
- Have a playlist-count > 99 on the first vo-configured. This makes
playlist() return before observing --osd-playlist-entry.
- Remove playlist entries until the count is < 100
- Change --osd-playlist-entry
- Show the playlist submenu before changing the playlist
Currently, if some log lines have very long text that actually
renders across multiple lines, even if you scroll to the top,
the topmost content will be pushed out of the screen by these
lines and will never be visible.
In STATS page 2/4/5/0, you can scroll down until there is one
line left on the screen, we can keep the scrolling behavior of
the log consistent with it.
Observing playlist-pos and playlist-count is not enough to update it
after playlist-move, but we can observe any playlist property with type
none to get notified of every MP_EVENT_CHANGE_PLAYLIST, even if the
property has not changed.
This is similar to the
mp.observe_property("vsync-jitter", "none", recorder) hack used by
stats.lua to replicate the deprecated tick event.
Fixes https://github.com/mpv-player/mpv/pull/16816#discussion_r2727498518
Rebind 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.
Make select.lua parse menu.conf on the first vo-configured and fill
menu-data with the properties referenced in menu.conf change. This is
disabled in the libmpv profile.
This is done from select.lua to reuse functions to format the data and
retrieve key bindings.
There is also a script-binding that opens the correct context menu
depending on --load-context-menu.
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. Since
it is not observable, it just uses the bindings from the first time the
context menu is opened.
Multimedia and numpad keys are also 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.
Avoid showing forced key bindings by modal scripts that temporarily
overwrite keybindings, like console and stats. These have section
input_forced_$scriptName. Unfortunately this skips all keybindings added
with mp.add_forced_key_binding even if you may want to show them.
Also skip the OSC sections "input" and "window-controls"; these sections
are not called input_forced_osc because the OSC uses
mp.enable_key_bindings() directly instead of mp.add_key_binding().
This mainly benefits the shortcuts in the context menu that the next
commit will add, but is also useful select/select-binding.
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 2011.
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.
When a character in an item's title is preceded by &, underline it and
activate the item when pressing the character.
Cycling between multiple items with the same hint is not supported.
&& escapes & so it works like the Windows context menu.
Hints after &&&, or greater odd numbers of &, are not supported since
Lua patterns don't support {n,m} quantifiers.
Don't reset system menu state, when menu data is empty, just disable the
items as needed. Fixes erratic behavior of system menu.
Fixes: 861908c70fFixes: #17290
Common layer should alter target params anymore, it's on specific VO to
set correct params. Also this should be noop anyway, after
dmabuf_wayland fix in previous commits.
This will do a little bit more than only setting max_luma. Also will
fallback to bt.709/bt.1886, but that's fine. We would do it anyway
later.
If params goes through guess_csp, they shouldn't have "unknown" fields
anymore.
Currently, we prefer selecting a track that matches the video program
ID, but can fall back on a track with a different program ID when there
is no such track or when no such track matches subs-fallback criteria.
Change this to instead select no track when only tracks with wrong PID
are available. Program ID will now act as a filter, not as a preference,
and only files with either matching or unset PID will be considered for
autoselect.
Also, ignore the program ID of external tracks, as it doesn't make much
sense to compare PIDs from different files.
The purpose of this test is mostly to verify that matching the OS
language is not wrongly prioritized over other things (like the forced
flag, matching the audio language, etc).
This is a copy of the existing locale test, but with forced flag added
to all tracks. The forced flag should not affect language selection in
this case.
When autoload-files=no, external files are never selected. Simplify the
logic by excluding them up front instead of removing them afterwards.
This doesn't change the outcome of track selection, apart from edge
cases that are already broken because compare_track is not transitive.
This fixes the problem that a subtitle track that normally wouldn't be
selected if it were the only track available could end up being selected
after a different candidate track was selected first.
sfan5