mpv/player/client.h

#ifndef MP_CLIENT_H_
#define MP_CLIENT_H_

#include <stdint.h>

#include "libmpv/client.h"

struct MPContext;
struct mpv_handle;
struct mp_client_api;
struct mp_log;

void mp_clients_init(struct MPContext *mpctx);
void mp_clients_destroy(struct MPContext *mpctx);
int mp_clients_num(struct MPContext *mpctx);

void mp_client_broadcast_event(struct MPContext *mpctx, int event, void *data);
int mp_client_send_event(struct MPContext *mpctx, const char *client_name,
                         int event, void *data);
void mp_client_property_change(struct MPContext *mpctx, const char **list);

struct mpv_handle *mp_new_client(struct mp_client_api *clients, const char *name);
struct mp_log *mp_client_get_log(struct mpv_handle *ctx);

#endif
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol). 2014-02-10 20:01:35 +00:00			`#ifndef MP_CLIENT_H_`
			`#define MP_CLIENT_H_`

			`#include <stdint.h>`

			`#include "libmpv/client.h"`

			`struct MPContext;`
			`struct mpv_handle;`
			`struct mp_client_api;`
			`struct mp_log;`

			`void mp_clients_init(struct MPContext *mpctx);`
			`void mp_clients_destroy(struct MPContext *mpctx);`
			`int mp_clients_num(struct MPContext *mpctx);`

			`void mp_client_broadcast_event(struct MPContext mpctx, int event, void data);`
			`int mp_client_send_event(struct MPContext mpctx, const char client_name,`
			`int event, void *data);`
client API: add a way to notify clients of property changes This turned out ridiculously complex. I think it will have to be simplified some day. Main reason for the complexity are: - filtering properties by forcing clients to observe individual properties explicitly (to avoid spamming clients with changes they don't want) - optional retrieval of property value with the notification (the basic idea was that this is more user friendly) - allowing to the client to specify a format in which the value should be retrieved (because if a property changes its type, the client API couldn't convert it properly, and compatibility would break) I don't know yet which of these are important, and everything could change. In particular, the interface and semantics should be adjusted to reduce the implementation complexity. While I consider the API complete, there could (and probably will) be bugs left. Also while the implementation is complete, it's inefficient. The complexity of the property matching is O(abc) with a clients, b observed properties, and c properties changing at once. I threw away an earlier implementation using bitmasks, because it was too unwieldy. 2014-04-05 21:54:21 +00:00			`void mp_client_property_change(struct MPContext mpctx, const char *list);`
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol). 2014-02-10 20:01:35 +00:00
			`struct mpv_handle mp_new_client(struct mp_client_api clients, const char *name);`
			`struct mp_log mp_client_get_log(struct mpv_handle ctx);`

			`#endif`