From 68d9d11ddf2817b682b0a9f87d4d42791d5666ca Mon Sep 17 00:00:00 2001 From: wm4 Date: Sat, 21 Mar 2020 14:44:09 +0100 Subject: player: playlist-pos now use -1 for "no entry selected" It's odd that this state is observable, but is made implicit by making the property unavailable. It's also odd that an API user cannot directly put the player into such a state. Just allow reading/writing -1 (or in fact, any out of bounds index) for this case. I'm also refraining from using OPT_CHOICE for the "no selection" case, because although that would be cleaner in theory, it would cause only problems to API users due to the more complex property type (worse is better). One reason for not restricting the integer range on the input property anymore is that if there are no playlist elements, the range would contain only 1 integer, which cannot be represented anymore since the recent m_option change. This was actually broken with 1 element playlists before (and still is, with the constricted type for OSD and the add/cycle commands). Doesn't matter too much. --- DOCS/interface-changes.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'DOCS/interface-changes.rst') diff --git a/DOCS/interface-changes.rst b/DOCS/interface-changes.rst index 4463930767..c63669ad7c 100644 --- a/DOCS/interface-changes.rst +++ b/DOCS/interface-changes.rst @@ -45,6 +45,9 @@ Interface changes notifications were interleaved in bad ways (it could happen that a property notification delivered after an event contained a value that was valid only before the event happened). + - the playlist-pos and playlist-pos-1 properties now can return and accept + -1, and are never unavailable. Out of range indexes are now accepted, but + behave like writing -1. --- mpv 0.32.0 --- - change behavior when using legacy option syntax with options that start with two dashes (``--`` instead of a ``-``). Now, using the recommended -- cgit v1.2.3