client API: declare mpv_suspend/mpv_resume deprecated

They're useless, and I have no idea what they're actually supposed to do
(wrt. pending input processing changes).

Also remove their implicit uses from the IPC handlers.
This commit is contained in:
wm4
2016-09-16 14:24:31 +02:00
parent 03fec24e19
commit 15baf2789c
8 changed files with 22 additions and 10 deletions

View File

@@ -39,6 +39,8 @@ API changes
mpv_initialize().
- do not override the SIGPIPE signal handler anymore. This was done as
workaround for the FFmpeg TLS code, which has been fixed long ago.
- deprecate mpv_suspend() and mpv_resume(). They will be stubbed out
in mpv 0.22.0.
--- mpv 0.19.0 ---
1.22 - add stream_cb API for custom protocols
--- mpv 0.18.1 ---

View File

@@ -63,6 +63,11 @@ Interface changes
treating it as a hardware overlay (without applying GL filtering). Also
to be changed in 0.22.0: the --fs flag will be reset to "no" by default
(like on the other platforms).
- deprecate "resume" and "suspend" IPC commands. They will be completely
removed in 0.22.0.
- deprecate mp.suspend(), mp.resume(), mp.resume_all() Lua scripting
commands, as well as setting mp.use_suspend. They will be completely
removed in 0.22.0.
- add almost all options to the property list, meaning you can change
options without adding "options/" to the property name (a new section
has been added to the manpage describing some conflicting behavior

View File

@@ -242,12 +242,16 @@ extra commands can also be used as part of the protocol:
command.
``suspend``
Deprecated, will be removed completely in 0.21.0.
Suspend the mpv main loop. There is a long-winded explanation of this in
the C API function ``mpv_suspend()``. In short, this prevents the player
from displaying the next video frame, so that you don't get blocked when
trying to access the player.
``resume``
Deprecated, will be removed completely in 0.21.0.
Undo one ``suspend`` call. ``suspend`` increments an internal counter, and
``resume`` decrements it. When 0 is reached, the player is actually resumed.