cocoawindow.m:339:5: error: 'NSOpenGLPFAWindow'
is deprecated: first deprecated in OS X 10.9
cocoawindow.m:576:7: error: 'NSOpenGLPFAFullScreen'
is deprecated: first deprecated in OS X 10.6
cocoawindow.m:605:24: error: 'setFullScreen'
is deprecated: first deprecated in OS X 10.7
The hack causes deadlocks and other interesting problems and it really
can only be fixed properly inside GLib. We will include a patch for
GLib in our builds for now that handles this, and hopefully at some
point GLib will also merge a proper solution.
A proper solution would first require to refactor the polling in
GMainContext to only provide a single fd, e.g. via epoll/kqueue
or a thread like the one added by our patch. Then this single
fd could be retrieved from the GMainContext and directly integrated
into a NSRunLoop.
https://bugzilla.gnome.org/show_bug.cgi?id=741450https://bugzilla.gnome.org/show_bug.cgi?id=704374
"have-ns-view" and the "embed" property was kept in 0.10 for
backwards compatibility but it's no longer used in favor of
the GstVideoOverlay interface
https://bugzilla.gnome.org/show_bug.cgi?id=703753
GetCurrentProcess/SetFrontProcess/TransformProcessType was deprecated
and now removed in Mac OSX 10.9. orderFrontRegardless is used to make
the video window the most front window.
And especially also consider update versions, e.g. 10.5 with updates
will be 1051 or similar and thus bigger than MAC_OS_X_VERSION_10_5 but
still won't have the API we want to use.
show_frame is deferred to the main thread and can be called
when the sink has been released, so we need to keep an extra ref
on ObjectiveC object helper.
https://bugzilla.gnome.org/show_bug.cgi?id=708501
Block gst_osx_video_sink_run_cocoa_loop until the loop thread has started and
finished initializing NSApp. Fixes occasional warnings/crashes due to two
threads going inside NSApp before finishLaunching had completed.
When we are using a dedicated thread to run the main run loop we
must make sure that all selectors are performed on this same thread.
For instance if performSelectorOnMainThread is called from the real
main thread, it will not go through the message queue and will be
executed from the real main thread. By forcing the target thread,
we ensure that all functions will be called either from the real
main thread when the main run loop is running or from our thread
spinning the main loop.
Add a little hack to run the cocoa main runloop from a separate thread _when_
the main runloop is not being run (which means that the app doesn't use cocoa).
Runloops are thread specific, so the hack boils down to getting the runloop for
the main thread and setting it as the runloop for our dedicated thread.
