| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was recently informed that unicode has official symbols for
window controls, and I put together a change to use them, which
worked, as long as a suitable font was installed. However, it's
not that hard to get a normal system that lacks an appropriate
font, and libass wants to print warnings if the symbols aren't
in the default font, which will almost always be true.
So, I gave up and added the symbols to the custom osd font that
we already have. This ensures they are always available, and
that they are aligned consistently on all platforms.
I took the symbols from the `symbola` font, as this has a suitable
licence and the symbols look nice enough.
Symbola Licence:
Fonts are free for any use; they may be opened, edited,
modified, regenerated, packaged and redistributed.
Finally, as we now have access to an un-maximize symbol, I added
logic to use it when the window is maximized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had previously wondered whether to do this, but in my testing
with x11 and wayland, the osc was being re-inited on a border
toggle already so I didn't add it.
However, on win32, things are different and there is no re-init
when toggling borders. I belive this is because the active window
size doesn't change in anyway, while on x11/wayland, toggling the
border actually changes the window size - and that trigger a re-init.
So, let's just be explicit and request a re-init when the border
is toggled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merged from mpv-repl git repo commit 5ea2bf64f9c239f0326b02. Some
changes were made on top of it:
- Tabs were converted to 4 spaces indentation (plus some manual
indentation fixes in some places).
- All user-visible mentions of "repl" were renamed to "console".
- The README was converted to a manpage (with heavy changes, some
additions taken from stats.rst; rossy converted the key bindings
table to RST).
- The method to change the default key binding was changed.
- Change minor detail about "font" default value setting (not a
functional change).
- Integrate into the player as builtin script, including an option to
prevent loading it.
Above changes and commit message done by wm4.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Later calls to mp.add_key_binding() should take priority over previous
calls with the same key. Until now, the order was random (due to using
table pairs() iteration order).
Do this by simply sorting by a counter that is never reset. Since
input.c also gives later bindings priority, this works out.
Calling mp.remove_key_binding() on a newer binding makes an older still
existing binding with the same key active again. New bindings override
older ones, but do not overwrite them. I think these are good semantics
for most use cases.
(Note that the Lua code cannot determine whether two bindings use the
same key. Keys are strings, and two different strings could refer to the
same key. The code does not have access to input.c's key name
normalization, so it cannot compare them.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the recent option changes (probably b16cea750f527), using the "vf"
or "af" commands to change the filter chain did not write the option
value correctly. This led to the option value being reset the next time
an option changed.
This happened because the new option value was not copied to the
m_config_cache's internal storage. So on the next option update, it
looked like the option value changed, because the user-side value was
different from the internal value. It was copied back, which meant the
original option value was reinstated, and the previous "vf"/"af" command
was undone.
Fix this by using the correct way to store the option value. This also
takes care of property change notification (because the function is
specifically separate from m_config_cache_write_opt() to do that), so
remove the old call.
Fixes: #7220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the "stop" and "loadfile" commands are asynchronous. "stop" starts
terminating playback, which used to be done in the same playloop
iteration, but now it may take longer, so a "loadfile" command can be
received while this is going on. (Possible that it used to work if the
second command was issued at least in the next playloop iteration.)
Make the "loadfile" override the "stop" mode, so the next file will be
played, instead of quitting or going into idle mode.
Unlike the referenced bug report claims, this has nothing to do with
IPC.
Fixes: #7225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To aid in discoverability, and to address the most common case
directly, I'm adding an 'auto' mode for the window controls. In
this case, we will show the controls if there is no window border
and hide them if there are borders. This also respects the option
being toggled at runtime.
To ensure that it works in the wayland case, I've also made sure
that the wayland code explicitly forces the option to false if
decoration support is missing.
Based on feedback, I've split the config in two, with one option
for whether controls are active, and one for alignment. These are
new enough that we can get away with ignoring compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As preparation for adding the auto mode for window controls, we need
to make sure that the controls can be successfully toggled at runtime,
rather than only being able to configure them once at startup. Right
now, there is a problem with the handling of the show/hide zone for
the window controls.
The previous fix for #7212 was to avoid registering the input mapping
for the window control show/hide zone. If there is no input mapping,
then there is no input, and the zone is a no-op, even if it exists.
But this only happens at startup. After that point, the input mapping
doesn't exist and cannot be turned on.
In this change, I'm switching the approach; we now go back to always
registering the input mapping, and instead, we zero out the show/hide
zone if window controls are disabled, and set its size appropriately
if they are enabled.
|
| |
|
|
|
|
| |
Certain backends (i.e. wayland) will need to do special things with the
mouse. It makes sense to expose the values of these options to them, so
they can behave correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hr-seek has some sort of tolerance against timestamps, where it allows
for up to 5ms deviation. This means it can work only for videos with up
to 200 FPS framerate. There were complains about how it doesn't work
with videos beyond some high fps. (1000 was mentioned, although that
sounds more like it's about the limit that .mkv has.)
I suspect this is because otherwise, it might be hard to hit a timestamp
with --start, which specifies timestamps as integer, and thus will most
likely never represent a timestamp exactly. Another part of the problem
is that mpv uses 64 bit floats for timestamps, so fractional parts are
never represented exactly. (Both the "tolerance" and using floats for
timestamps were things introduced before my time.)
Anyway, in the backstep case, we can be relatively sure that the
timestamp will be exact (as in, the same unmodified value that was
returned by the filter chain), so we can make an exception for that, in
order to fix backstep.
Untested. (For that you have users.)
May help with #7208.
|
| |
|
|
|
|
|
|
| |
I always intended for this to be accepted and mean "right" but I
made it show an error for any value that's not explicitly
recognised (while considering all unrecognised values to mean "right").
So let's explicitly recognise "yes".
|
| |
|
|
|
| |
Only set the window control keybindings if the window control option is
actually enabled. Fixes #7212.
|
| |
|
|
|
|
|
|
|
|
|
| |
I wanted to get this done quickly as I introduced the new VOCTRL
behaviour for minimize and maximize and it was immediately made
legacy, so best to purge it before anyone gets confused.
I did not sort out fullscreen as that's more involved and not something
I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN
usage with the new option change mechanism as that seemed simple
enough.
|
| |
|
|
|
|
| |
This is necessary to avoid breaking input behaviour in the 'idle'
state when not playing a video. Otherwise, the mouse area starts off
covering the whole window and blocks normal input.
|
| |
|
|
|
| |
This is in addition to the allowed omission of name and/or flags (as
documented).
|
| |
|
|
|
|
|
| |
Commit 311cc5b6 added the ability use flags while omitting name, but
broke the case where both name and flags are omitted.
Now omitting either name or flags or both works as documented.
|
| | |
|
| |
|
|
|
|
| |
It seems logical to account for the window controls if `boxvideo`
is in use (which has the effect of reducing the size of the video
so that the osc is not covering the video).
|
| |
|
|
|
|
| |
Properties should handle this themselves. This basically sent redundant
notifications. I found only two places where the "proper" notification
was missing.
|
| |
|
|
| |
Due to recent changes, it makes no sense anymore to keep them separate.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that the option-to-property bridge is gone, this is not needed
anymore. It always took the "silent" path.
Also, at least as of before this commit, this didn't correctly print a
warning when accessing a deprecated option as property. This was because
m_config_get_co_raw() was used, which intentionally does not print any
warnings, so switch to the non-raw one. (Affects only options that have
.deprecation_message set.)
|
| |
|
|
|
| |
It seems this area is simply not defined when window controls are
disabled, so ipairs() will crash on it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I missed these due to only testing with my personal osc config.
The deadzone needs to be correctly handled for the window controls,
or they will fail to appear when the mouse is close to or over them.
In the process of doing that, I realised that the controls should
respect the barmargin, if set. This is because the controls should
remain aligned when layout=topbar and as the control bar is top
aligned, it should be equally affected if the user needs to set
the barmargin.
I also fixed a mistake in trying to the use the mpv-osd-symbols font
for the window controls.
|
| |
|
|
|
| |
Unfortunately, this breaks window state reporting for all VOs which
supported it. This can be fixed later (for x11 in the next commit).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of making m_config a special-case, it more or less uses the
underlying m_config_cache/m_config_shadow APIs properly. This makes the
player core a (relatively) equivalent user of the core option API. In
particular, this means that other threads can change core options with
m_config_cache_write_opt() calls (before this commit, this merely led to
diverging option values).
An important change is that before this commit, mpctx->opts contained
the "master copy" of all option data. Now it's just another copy of the
option data, and the shadow copy is considered the master. This is why
whenever mpctx->opts is written, the change needs to be copied to the
master (thus why this commits add a bunch of m_config_notify... calls).
If another thread (e.g. a VO) changes an option, async_change_cb is now
invoked, which funnels the change notification through the player's
layers.
The new self_notification parameter on mp_option_change_callback is so
that m_config_notify... doesn't trigger recursion, and it's used in
cases where the change was already "processed". It's still needed to
trigger libmpv property updates. (I considered using an extra
m_config_cache for that, but it'd only cause problems with no
advantages.)
I think the recent changes actually forgot to send libmpv property
updates in some cases. This should fix this anyway. In some cases,
property updates are reworked, and the potential for bugs should be
lower (probably).
The primary point of this change is to allow external updates, for
example by a VO writing the fullscreen option if the window state is
changed by the window manager (rather than mpv changing it). This is not
used yet, but the following commits will.
|
| |
|
|
|
|
|
| |
Just an implementation detail that can be cleaned up now. Internally,
m_config maintains a tree of m_sub_options structs, except for the root
it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to
it anyway. Define it explicitly instead.
|
| |
|
|
| |
No more converting the option values to a string to compare it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, if window decorations are not present, either because they were
disabled, or because the platform doesn't support them
(eg: gnome-shell on wayland), there are no window controls, meaning it
is not possible to minimize/maximize/close a window without knowing
keyboard shortcuts.
While you can imagine various ways of offering client side decorations,
it is attractive to consider using OSC because that is functionality
that we already have.
The main work here is defining a separate input area from the main
OSC box with its own buttons, etc.
While we could probably handle auto-detection based on whether
decorations are present or not, it's manually controlled for now.
The window control logic is mostly disconnected from the OSC itself,
except in the case of the `topbar` layout, where there has to be
coordination so that the controls don't get drawn on top of each other.
I had to do fine-positioning of the buttons based on the font on
my system, so don't be surprised if it looks wrong elsewhere.
You could also argue that window controls should be unscaled, even
if the main OSC box is scaled, but I've not tried to do this.
|
| |
|
|
|
|
|
|
|
|
|
| |
If we want to implement window pseudo-decorations via OSC, we need a
way to tell the vo to minimize and maximize the window. Today, we have
minimized as a read-only property, and no property for maximized.
Let's made minimized settable and add a maximized property to go with
it. In turn, that requires us to add VOCTRLs for minimizing or
maximizing a window, and an additional WIN_STATE to indicate a
maximized window.
|
| |
|
|
|
|
|
|
| |
The previous bunch of commits made this unnecessary, so this should be
a purely internal change with no user impact.
This may or may not open the way to future improvements. Even if not,
at least the property/option interaction should now be much less buggy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert some remaining properties to work without the option-to-property
bridge. Behavior shouldn't change (except for the corner case that it
tries to reapply the new state when setting a property, while it used to
ignore redundant sets).
As it is the case with many of these changes, much of the code is not in
its final proper state yet, but is rather a temporary workaround. For
example, these "VO flag" properties should just be fully handled in the
VO backend. (Currently, the config or VO layers don't provide enough
mechanism yet as that all the backends like x11, win32, etc. could be
changed yet, but that's another refactoring mess for another time.)
Now nothing relies on this option-to-property bridge anymore, which
opens the way to even more refactoring, which eventually may result in
tiny improvements for the end user.
|
| |
|
|
|
| |
Again in line with the option-to-property bridge changes. As usual, this
causes subtle behavior changes, which may affect some users.
|
| |
|
|
|
|
| |
The behavior is slightly different in a messy way. The change is in line
with the option-to-property bridge removal mentioned some commits ago
and thus is deemed necessary.
|
| |
|
|
|
|
| |
This attempted to restore the old filter chain if setting a new one at
runtime failed. This is not needed anymore, because changing the filter
chain is done in a "transactional" way now.
|
| |
|
|
|
|
|
| |
See changelog and manpage changes.
(So much effort to fix an ancient dumb mistake for an option nobody
should use anyway.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is preparation to get rid of the option-to-property bridge
(mp_on_set_option). This is a pretty insane thing that redirects
accesses to options to properties. It was needed in the ever ongoing
transition from something to... something else.
A good example for the need of this bridge is applying profiles at
runtime. This obviously goes through the config parser, but should also
make all changes effective, for which traditionally the property layer
is used.
There isn't much left that needs this bridge. This commit changes a
bunch of options (which also have a property implementation) to use
option change notifications instead. Many of the properties are still
left, but perform unrelated functions like OSD formatting.
This should be mostly compatible. There may be some subtle behavior
changes. For example, "hwdec" and "record-file" do not check for changes
anymore before applying them, so writing the current value to them
suddenly does something, while it was ignored before.
DVB changes untested, but should work.
|
| |
|
|
|
|
|
|
| |
add_key_binding() makes the name argument optional (in weird Lua
fashion), which did not work if there were additional arguments. So
there is no way to avoid specifying a name while passing a rp argument.
Fix this, declare this way of skipping the argument as deprecated, and
allow passing name=nil as the preferred way to skip the name argument.
|
| |
|
|
|
|
| |
Read-only information about all bindings. Somewhat hoping someone can
make a nice GUI-like overlay thing for it, which provides information
about mapped keys.
|
| | |
|
| |
|
|
|
|
|
|
| |
No reason to have this as bstr, just makes everything more complex.
Also clear mp_cmd.sender when it's copied. Otherwise it would be a
dangling pointer. Apparently it's never set to non-NULL in this
situation, but this is cleaner anyway.
|
| |
|
|
|
|
|
| |
Particularly for "any_unicode" mappings, so they don't have to
special-case keys like '#' and ' ', which are normally mapped to
symbolic names for input.conf reasons. (Though admittedly, this is a
pretty minor thing, since API users could map these manually.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I often watch sporting events. On many occasions I get files with the
same filename for each session. For example, for F1 I might have the
following directory structure:
F1/
FP1.mkv
FP2.mkv
FP3.mkv
Qualification.mkv
Race.mkv
Since usually one simply watches one race after the other, I usually
just rsync the new event's files over the old ones, so, for example,
Race.mkv will be replaced from the file for the last event with the file
from the new event.
One problem with this is that I like to use --resume-playback for other
kinds of media, so I have it on by default. That works great for, say, a
movie, but doesn't work so well with this scheme, because you can
trivially forget to pass --no-resume-playback on the command line and
end up 2 hours in, watching spoilers as the race results scroll down the
screen :-)
This patch adds a new option, --resume-playback-check-mtime, which
validates that the file's mtime hasn't changed since the watch_later
configuration was saved. It does this by setting the watch_later
configuration to have the same mtime as the file after it is saved.
Switching back and forth between checking mtime and not checking mtime
works fine, as we only choose whether to compare based on it, but we
update the watch_later configuration mtime regardless of its value.
|
| |
|
|
| |
This might make certain use cases less of a mess.
|
| |
|
|
| |
Match lua's 8e5642ff
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
