summaryrefslogtreecommitdiffstats
path: root/DOCS/client_api_examples
Commit message (Collapse)AuthorAgeFilesLines
* DOCS/client_api_examples: qtexample: remove broken resizingwm42014-09-281-8/+6
| | | | | | | | | The intention was to adjust the window size to video size. It never worked well; it prevented the user to make the window smaller. For unknown reason it stopped resizing properly as well. This is just a cheap example, and I don't intend to fight with Qt, so replace the "demonstration" behavior by something slightly lamer.
* client API, X11: change default keyboard input handling againwm42014-09-282-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.
* DOCS/client_api_examples: qtexample: resize to video sizewm42014-09-151-0/+21
| | | | | | | | | | | | | This is pretty imperfect, but it's just a demo. The main purpose is clarifying how and when to get the video size. In theory, retrieving the properties this way has a race condition: after reading dwidth, the video could resize again. But the worst that can happen are mismatching dwidth/dheight values, and the MPV_EVENT_VIDEO_RECONFIG event would be immediately received again, which would fix the mismatch. You could read the full video-out-params property to absolutely avoid it, but it's not worth the trouble.
* docs: cocoa example uses wakeup callback APIFRAU KOUJIRO2014-08-121-22/+54
| | | | Also, imitate the qt example somewhat.
* docs: simple cocoa API usage exampleFRAU KOUJIRO2014-08-121-0/+85
|
* client API: qtexample: don't pass deallocated strings to mpvwm42014-08-071-1/+2
| | | | | The temporary QByteArray is deallocated already at the end of the statement in C++, instead of the end of the scope (like in C).
* DOCS/client_api_examples: add a Qt examplewm42014-07-043-0/+177
| | | | | This is pretty dumb and extremely basic. The main purpose is demonstrating how to integrate mpv into the Qt GUI thread.
* client API: rename mpv_destroy() to mpv_detach_destroy()wm42014-06-071-1/+1
| | | | | | A bit verbose, but less misleading. In most cases, the API user probably actually wants mpv_terminate_destroy() instead, so the less-useful function shouldn't have a simnpler name anyway.
* client api examples: set an option with MPV_FORMAT_FLAGwm42014-02-241-1/+2
|
* Add a client API examplewm42014-02-102-0/+53