[vlc-devel] [vlc-commits] macosx: run on first thread directly, like already done by Qt4

[Felix Paul Kühne]

On 09.05.2012, at 11:48, Rémi Denis-Courmont wrote:

>   Hello,
> 
> On Wed, 9 May 2012 11:08:38 +0200, Felix Paul Kühne
> <fkuehne.videolan at gmail.com> wrote:
>>> vlc | branch: master | Rémi Denis-Courmont <remi at remlab.net> | Mon May 
>>> 7 19:57:10 2012 +0300| [a11c642f29bf4f163551d2aece30ff01b329321c] |
>>> committer: Rémi Denis-Courmont
>>> 
>>> macosx: run on first thread directly, like already done by Qt4
>> 
>> even though your newly committed code looks quite familiar and similar
> to
>> the existing one, it breaks the execution on OS X.
> 
> From my perspective, execution never worked correctly on MacOS. So I
> cannot have broken something that was already broken.
Well, it worked from the end-user's perspective.


> libvlc_add_intf() is not allowed to block as per design and documentation.
> The MacOS UI does block it. Consequently, just about every time a change is
> made in the VLC initialization sequence, MacOS breaks. This just yet
> another occurence.
Well, no, this has been quite stable for the last revisions.


> Not only does that break LibVLC, but it breaks QuickTime capture, POSIX
> signal handling, automatic playlist startup, running VLC headless, clean
> exit, and what else am I not aware of.
1) QTKit is a broken concept. Basically, you should implement it on your own, if you wish to use it in 3rd party apps. It doesn't make sense to use it through VLCKit. Additionally, you already stated that you won't support main thread handling through libvlc, so this argument is moot. Capturing stuff from the QTKit access modules within the ordinary VLC.app works correctly.
2) POSIX signal handling is blocked by the OS X ui. This isn't related to your changes and should be worked-out indeed. I'm aware of the trac ticket.
3) works for me.
4) works for me.
5) works for me.
6) I'm not aware of anything else either.

> 
>> The Cocoa main thread fails to initialize, so the Mac interface is never
> being
>> displayed.
> 
> Probably something is missing or badly ordered between Open() and Run().
Yes, probably. I'll see if I can do anything.

> I will not look at it because I have no time, no expertise, no hardware and
> no interest in doing so.
> 
>> If desired, I can demonstrate you the issue on jones.
> 
> Not me, thanks.
So you are interested in breaking working code, but aren't in fixing it correctly so people can actually take benefit from your contribution? This is an interesting concept.


Best regards,

Felix