Cocoa!

MacOSX and iOS
1

Ok, I’ve finally got the new cocoa changes into a decent state and have checked it in. It’s been a total nightmare to rewrite all this!

So please grab the tip and have a go, and see what you reckon. I’m not 100% finished yet - you can now build apps without linking to the dreaded Carbon.framework, but there are a couple of bits left (the font rendering and quicktime streams) that need rewriting before you can compile a 64-bit app. Will get onto those next.

There are a few caveats if you’re writing RTAS/VSTs, or hosting them - there still needs to be a few bits of carbon glue code to get these things working, but the UIs are now entirely cocoa-based, which helps with performance. AUs will now only run in cocoa AU hosts (which is probably all of the important ones?) but I’ve kept the carbon AU hosting as an option so it can handle both.

There are so many changes and things to check that I’ve been a bit overwhelmed by the task of checking all this stuff, so would greatly appreciate anyone letting me know of any obvious mistakes!

I’ve also rejigged the format of the native code files slightly, and am preparing to have a complete overhaul of these, turning them into a sort of library-within-a-library to handle the low-level cross-platform stuff, but that’s another story…

Anyway, have fun…

2

Hi Jules,

First of all, that’s a great news. Great job. Thanks a lot.

I was wondering if after those changes it will be still possible to compile carbon versions.
For example having the 32 bits version of Juce using Carbon and the 64 bits one using Cocoa.

As a plugin developer, I’m thinking to all the legacy stuff we tend to still support and that would be hard I suppose to make it work with a Cocoa UI.

Thanks,

3

For building apps, it’s cocoa all the way, but there’s no problem there with backwards-compatibility.

For VSTs, it wraps a carbon window around your cocoa UI, so hopefully that should all still work. (Of course the entire VST SDK itself will get ditched when Apple finally deprecate carbon).

For AUs, you can’t build a carbon UI any longer, only a cocoa one, but I think most hosts shouldn’t have a problem with that, and it does work better.

For RTAS, it uses a carbon wrapper around a cocoa window, so again, that should be ok.

But there are so many permutations when building plugins like this, that I feel like it’s impossible for me to test everything properly - I’d really appreciate any feedback that people have when trying to build their plugins with this new code!

4

Ehm, first question from my side: Does the Timer class now work? You remember, until now, it caused troubles (stopped issuing timer messages) on slower machines in Plugins, but only in some hosts (I think Cocoa hosts).

5

Well, I never changed the timer code, but yes, it’ll work now because the messages are sent via the same mechanism that delivers native timer events.

6

Ok. Meanwhile, can’t compile. Here are the errors (just grabbed the whole tree using SVN and tried to compile with XCode 2.4.1 on OS X Tiger 10.4.11):

<snip: don’t need to see the errors, so tidied this up for brevity…>

7

I think you’ll need XCode 3, or at least 2.5. I no longer have anything prior to that, so can’t test against it.

8

I had to change an NSInteger to int in order to compile juce in juce_mac_NSViewComponentPeer.mm

I am on 10.5 building with the 10.5sdk with xcode 3.0

I’ve seen another thread where you said that NSInteger was 10.5 specific.

9

Using XCode3 would require installing Leopard. I just don’t want to do that.
Will JUCE projects, compiled with XCode3 still run under Tiger ?

10

[quote=“mdsp”]I had to change an NSInteger to int in order to compile juce in juce_mac_NSViewComponentPeer.mm

I am on 10.5 building with the 10.5sdk with xcode 3.0

I’ve seen another thread where you said that NSInteger was 10.5 specific.[/quote]

Hmm - I use the same config, but it compiles ok… Oh well, I can change it to an int without any problems.

11

Will JUCE projects, compiled with XCode3 still run under Tiger ?

12

hi, I’ve tried with the standalone version of one of our products and for some reason there is 30 or 40px being cropped at the bottom

I’m using a juce::DocumentWindow with setContentComponent()

any ideas? or additional initialization stuff I need to perform?

13

Which one is tiger? 10.4? I can never remember which cat is which…

It’ll still all compile for 10.3.9 onwards, I think. I’ve been testing with 10.4 and 10.5. There are so many different combinations though, that there might be bits I need to tweak.

[quote]hi, I’ve tried with the standalone version of one of our products and for some reason there is 30 or 40px being cropped at the bottom

I’m using a juce::DocumentWindow with setContentComponent()

any ideas? or additional initialization stuff I need to perform?[/quote]

Very odd! No, can’t think of anything offhand, though it must be to do with the window’s frame vs content rectangles. Are you using a native title bar?

14

yes

I’ll make some more test to let you know

15

Yes, that’s 10.4 . I’ll have a try with XCode2.5 for compiling - but if it doesn’t work, will I be forced to use XCode3 ? Is there no workaround for:

  • getting XCode 3 work on 10.4.11 ?
  • getting JUCE compiled without having to install XCode3 in case of XCode2.5 failing to compile it?

By the way, is XCode3 really that faster? I read some claims that compile times were 4x shorter?

16

xcode 3 is much better. 2.5 is the version that they say you should be using if you’re still on 10.4, because it’s compatible with the way 3.0 builds.

17

yes

I’ll make some more test to let you know[/quote]

I don’t have the cropped bottom if I use juce’s own title bar.

18

Did you try doing 64-bit build yet Jules? Or those fancy 4 way Universal Binaries?

Bruce

19

yes

I’ll make some more test to let you know[/quote]

I don’t have the cropped bottom if I use juce’s own title bar.[/quote]

hmm. But the juce demo seems to run fine with the native title bar… Is there anything you can think of that I could do to try to recreate it?

I tried, but there are still a couple of last bits I need to do before it’ll work as 64-bit…

20

I am pretty sure this is related to the bug I posted a few days ago about screen coordinates not being correct and my app window going behind the OS X Menu Bar on the top. The latter problem also did not occur with the JUCE demo when I tried to recreate it, although I found no reason for it to be different.

BTW, just tried compiling with XCode2.5, with 10.4 SDK and 10.5 SDK, it’s all the same, I always get the same errors as mentioned above.

Please, if anybody succeeds in compiling with XCode2.5 let me know. Cheers! Seriously, you can’t expect everybody who wants to compile JUCE to have 10.5.