diff options
author | wm4 <wm4@nowhere> | 2017-04-01 20:36:39 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-04-01 20:36:39 +0200 |
commit | a071d5fcfeee4cc0ac58a4e0cf1968c8c92ff080 (patch) | |
tree | 9ad851a36cba05801f691e7360ea5001b540ef65 /libmpv/client.h | |
parent | ec3dd7164ceea9ceda71e05e774501874fd20924 (diff) | |
download | mpv-a071d5fcfeee4cc0ac58a4e0cf1968c8c92ff080.tar.bz2 mpv-a071d5fcfeee4cc0ac58a4e0cf1968c8c92ff080.tar.xz |
input: add "async" flag
Obviously, this has no effect on commands which do not support this
explicitly. A later commit will enable this for screenshots.
Also add some wording on mpv_command_async(), which has nothing to do
with this. Having a more elegant, unified behavior would be nice. But
the API function was not created for this - it's merely for running
commands _synchronously_ on the core, but without blocking the client
API caller (if the API user consistently uses only async functions).
Diffstat (limited to 'libmpv/client.h')
-rw-r--r-- | libmpv/client.h | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/libmpv/client.h b/libmpv/client.h index a016df691f..ee4290e22b 100644 --- a/libmpv/client.h +++ b/libmpv/client.h @@ -879,6 +879,10 @@ int mpv_command_string(mpv_handle *ctx, const char *args); * MPV_EVENT_COMMAND_REPLY event. (This event will also have an * error code set if running the command failed.) * + * This has nothing to do with the "async" command prefix, although they might + * be unified in the future. For now, calling this API means that the command + * will be synchronously executed on the core, without blocking the API user. + * * @param reply_userdata the value mpv_event.reply_userdata of the reply will * be set to (see section about asynchronous calls) * @param args NULL-terminated list of strings (see mpv_command()) |