From b2646911a900cf3cb9c6e90aa28066c7be91abaf Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 4 May 2016 17:37:54 +0200 Subject: client API: access choices as flags if appropriate Options/properties that are choices, and which include "yes" or "no" values (or both) can now be read and written as MPV_FORMAT_FLAG. For write access, rejecting flags in these cases was obnoxiously unintuitive and inconvenient. For read access, the value of this is less convincing, and actually it's a major API change. At this point I probably have to admit that the finer details of the client API are very unstable. --- DOCS/client-api-changes.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'DOCS/client-api-changes.rst') diff --git a/DOCS/client-api-changes.rst b/DOCS/client-api-changes.rst index 44490ea79d..8fcdf83e32 100644 --- a/DOCS/client-api-changes.rst +++ b/DOCS/client-api-changes.rst @@ -41,6 +41,11 @@ API changes is invoked with that type directly. This new behavior is equivalent to mpv_set_option(). This also affects the mp.set_property_native() Lua function. + - generally, setting choice options/properties with "yes"/"no" options + can now be set as MPV_FORMAT_FLAG + - reading a choice property as MPV_FORMAT_NODE will now return a + MPV_FORMAT_FLAG value if the choice is "yes" (true) or "no" (false) + This implicitly affects Lua and JSON IPC interfaces as well. --- mpv 0.12.0 --- 1.20 - deprecate "GL_MP_D3D_interfaces"/"glMPGetD3DInterface", and introduce "GL_MP_MPGetNativeDisplay"/"glMPGetNativeDisplay" (this is a -- cgit v1.2.3