diff options
| author | wm4 <wm4@nowhere> | 2020-08-07 19:39:46 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2020-08-07 19:41:56 +0200 |
| commit | 1f132c675a18f0b80fc3159a7b13b5b061f2d93c (patch) | |
| tree | bb421d3c4dcae749c4161bd3e2abeb981c28ee44 /DOCS/man/input.rst | |
| parent | d5a02dd9342f5c61f3e3a9caf2082dd46b5099e3 (diff) | |
| download | mpv-1f132c675a18f0b80fc3159a7b13b5b061f2d93c.tar.bz2 mpv-1f132c675a18f0b80fc3159a7b13b5b061f2d93c.tar.xz | |
options: add some way to more or less "unapply" profiles
Make it possible to restore from profiles by backing up the option
values before profile application. This is sort of like unapplying a
profile. Since there might be multiple ways to do this, a profile needs
to explicitly provide the "profile-restore" option, which specifies how
exactly this should be done.
This is a big mess. There is not natural way to do this. Profile
application is "destructive" and simply changes the values of the
options. Maybe one could argue that the option system should have
hierarchical "overlays" of profiles instead, where unset options will
use the value of the lower profiles. Options set interactively by the
user would be the top profile. Default values would be in the lowest
profile. You could unapply a profile by simply removing it from this
overlay stack.
But uh, let's not, so here's something stupid. It reuses some code used
for file local options to reduce code size. At least the overlay idea
would still be possible in theory, and could be added as another
profile-restore mode.
This is used by the following commit.
Diffstat (limited to 'DOCS/man/input.rst')
| -rw-r--r-- | DOCS/man/input.rst | 14 |
1 files changed, 11 insertions, 3 deletions
diff --git a/DOCS/man/input.rst b/DOCS/man/input.rst index 6df7890383..8593dd75a2 100644 --- a/DOCS/man/input.rst +++ b/DOCS/man/input.rst @@ -1220,13 +1220,21 @@ Input Commands that are Possibly Subject to Change ``af-command <label> <command> <argument>`` Same as ``vf-command``, but for audio filters. -``apply-profile <name>`` +``apply-profile <name> [<mode>]`` Apply the contents of a named profile. This is like using ``profile=name`` in a config file, except you can map it to a key binding to change it at runtime. - There is no such thing as "unapplying" a profile - applying a profile - merely sets all option values listed within the profile. + The mode argument: + + ``default`` + Apply the profile. Default if the argument is omitted. + + ``restore`` + Restore options set by a previous ``apply-profile`` command for this + profile. Only works if the profile has ``profile-restore`` set to a + relevant mode. Prints a warning if nothing could be done. See + `Runtime profiles`_ for details. ``load-script <filename>`` Load a script, similar to the ``--script`` option. Whether this waits for |