I’m making a cross-platform VST module and was puzzled by its behavior on OSX, where the editor window didn’t behave as other windows: The title bar didn’t indicate that the window had focus, you couldn’t give it focus by clicking on the title bar, there was trouble bringing it to front and minimizing it. Looking into the matter, I found out about the rather special way this is solved, with a frameless Cocoa window floating above an empty Carbon window. My guess is that this has to do with carbon-cocoa integration prior to OSX 10.2, when such integration was a major problem. But that is only a guess, and there might be other reasons as well. Before I go through the painful process of modifying the wrapper to use the OSX >= 10.2 methods using initWithWindowRef, can anyone please tell me if there are other reasons why this might not work (particular vst hosts that misbehave, etc). Testing done partially with Juce 1.51, partially with GIT-downloaded repository from 2 days ago.
Yes, it’s a horrible bodge, but it’s not because of OSX 10.2, it’s because the VST SDK was designed to use Carbon for its UI. I think they’ve sorted that out in the new just-released version of the SDK, but I’ve not yet had chance to look at it, (and it’ll take some time before the hosts catch up anyway…)
The reason I mentioned 10.2 is that that was the version of osx when it first became possible to create a cocoa window having a carbon window as its parent, which is what’s needed here. I’m trying to modify the wrapper to make use of that, but of course all the events and window behaviours have to be translated back and fourth between carbon and cocoa, which is a bit of a pain.
I’m pretty sure that functionality only arrived in 10.4 or 10.5, or I’d definitely have used it. Juce has never had compatibility for pre-10.3 systems, so I’d certainly have used the OS support for that if it had been possible.
But it’s a good point - I could revisit that code now that it’s not unreasonable to drop 10.3 support.