Draft: darwinvlc: start interfaces (qt, macosx) in separate thread
Interfaces from libvlc were started from the main thread directly. But UI inserting their own event loop inside the main runloop like Qt were taking over the interface insertion. It was preventing other interfaces to load correctly, required dedicated code to handle the startup in the Qt interface and it was not possible to exit the interface correctly.
By moving the creation of the interfaces in a dedicated thread, we can ensure all UI are created and destroyed correctly, but the macosx interface must now dispatch its own creation into the main thread to match Cocoa requirement on main thread usage for UI components.
Now that the interfaces are not run from the main thread directly, it's possible to dispatch the QApplication startup and UI creation to the main thread directly on Darwin. It matches the behaviour of the interface on other platform that Darwin, where a thread is created to handle the interface, except that the thread is already existing as the main thread for Darwin.
It means that there won't need any specific code (except for Thread() startup) to handle the specificities of the Qt interface startup on Darwin anymore.
Ticket #27103 showed issues when leaving the interface with the medialibrary, because the path releasing the medialibrary was not taken correctly, but other issues could arise, including deadlocks.
Fixes #27103
Note:
The MR is in a draft state because even though it fixes the Qt interface, it completely breaks the Macos interface. Indeed, nothing displays anymore, and now the macosx interface cannot define the NSApp that will be used for the application definition. But conversely, Qt starts the NSApp on its own with QApplication::exec() so there is a discrepancy of wanted behaviour here.
Some more thoughts to fix thoses are needed. Any thought @ePirat ?