path: root/DOCS/client-api-changes.rst
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.7.0v0.7.0Alessandro Ghedini2014-11-251-0/+1
* input, lua: redo input handlingwm42014-11-231-0/+2
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* client API: deprecate some eventswm42014-11-081-0/+9
| | | | | | | | | | | Following the discussion in #1253. The events won't be removed for a while, though. (Or maybe never, unless we run out of bits for the uint64_t event mask.) This is not a real change (the events still work, and the alternative mechanisms were established a few API revisions earlier), but for the sake of notifying API users, update DOCS/client-api-changes.rst.
* client API: qthelper: add set_option_variant()wm42014-10-301-0/+1
* player: add an option to abort playback on partial init failureswm42014-10-281-0/+2
| | | | | | This is probably what libmpv users want; and it also improves error reporting (or we'd have to add a way to communicate such mid-playback failures as events).
* client API: better error reportingwm42014-10-281-0/+2
| | | | Give somewhat more information on playback failure.
* client API: add an enum for mpv_event_end_file.reasonwm42014-10-281-0/+1
| | | | | | | | | Using magic integer values was an attempt to keep the API less verbose. But it was probably not a good idea. Reason 1 (restart) is not made explicit, because it is not used anymore starting with the previous commit. For ABI compatibility, the value is left as a hole in the enum.
* client API: add qthelper.hppwm42014-10-131-0/+1
| | | | | | | | | | | | | | This provides some helper functions and classes for C++/Qt. As the top of qthelper.hpp says, this is built on top of the client API, and is a mere helper provided for convenience. Maybe this should be a separate library, but on the other hand I don't see much of a point in that. It's also header-only, but C++ people like such things. This makes it easier for us, because we don't need to care about ABI compatibility. The client API doesn't change, but bump it so that those who are using this header can declare a proper dependency.
* client API: add mpv_command_node[_async]wm42014-10-111-0/+1
| | | | | | | | | Allows passing native types as arguments. Also some minor doc improvements, including giving some (natural) improvements to mpv_free_node_contents(). Note: mpv_command_node_async() is completely untested.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-091-0/+2
| | | | | Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
* client API: introduce numeric log levelswm42014-10-081-0/+1
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
* msg, client API: buffer partial lineswm42014-10-081-0/+1
| | | | | | | | | | | | | | | The API could return partial lines, meaning the message could stop in the middle of a line, and the next message would have the rest of it (or just the next part of it). This was a pain for the user, so do the nasty task of buffering the lines ourselves. Now only complete lines are sent. To make things even easier for the API user, don't put multiple lines into a single event, but split them. The terminal output code needed something similar (inserting a prefix header on start of each line). To avoid code duplication, this commit refactors the terminal output so that lines are split in a single place.
* client API: clarify pause/unpause events, modify core-idle propertywm42014-10-071-0/+2
| | | | | | | | Whether you consider the semantics weird or not depends on your use case, but I suppose it's a bit confusing anyway. At this point, we keep MPV_EVENT_PAUSE/UNPAUSE for compatibility only. Make the "core-idle" property somewhat more useful in this context.
* client API, X11: change default keyboard input handling againwm42014-09-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-0/+1
| | | | | | | | | | | | | | | | | | | When embedding a X window, it's hard to control whether it receives mouse/keyboard input or not. It seems the X protocol itself makes this hard (basically due to the outdated design mismatching with modern toolkits), and we have to take care of these things explicitly. Simply do this by manually querying and using the parent window event flags. This restores some MPlayer behavior (it doesn't add back exactly the same code, but it's very similar). This probably has some potential to interfere with libmpv embedding, so bump the client API minor. CC: @mpv-player/stable (if applied, client-api-changes.rst has to be adjusted to include the 0.5.2 release)
* DOCS: mark the recent release in client-api-changes.rstwm42014-08-121-0/+1
| | | | | | | Also add instructions to, since this can be easily forgotten. CC: @mpv-player/stable
* client API: add and use the MPV_MAKE_VERSION macrowm42014-08-051-0/+1
| | | | | | | This is probably nicer. The actual version number doesn't change (other than the minor being incremented). The "| 0UL" is to make the type unsigned long int, like it was before.
* Remove stream_pts stuffwm42014-07-061-0/+1
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* DOCS/client-api-changes: try to fix rst formatting againwm42014-07-061-3/+4
* DOCS, client API: add mpv release versionswm42014-07-051-0/+3
| | | | | | | | The intention is to make it obvious which mpv releases certain changes will apply to. Also attempt to fix RST formatting of the list. This is not very proper, but probably good enough.
* DOCS: add a file listing API changes for the client APIwm42014-07-031-0/+35