Is Juce migrating to Cocoa soon?

MacOSX and iOS
1

Hi,

Apple in WWDC 2007 announced the drop of Carbon 64-bit support in Leopard O/S. Wonder if there’s any plans for Juce to port the current framework to Cocoa soon?

Thanks.

2

I don’t think that’s actually possible, is it?? Has anyone ever tried mixing obj-c with c++ and lived to tell the tale?

3

Sure it is. But apart from that, Carbon isn’t getting moved to 64 bit. That doesn’t mean you have to use Cocoa, necessarily. If you can move to Core Foundation (CFnnnNnnnn) then that will probably be fine.

My guess - the 80 or so deprecated messages you get in a Tiger compile are it.

Bruce

4

So is it possible to implement c++ methods using obj-c code? If so, then I guess it’d just be a case of rewriting the platform-specific files in obj-c, which is probably not too hard.

5

Now I think about it, maybe that’s not the case. Those (124) warnings may just stop working in Leopard. Possibly a 64 bit build will balk at more. But Juce uses marvelously few OS calls, so maybe not.

At least, everything in QD.framework will break:
GetPort, SetPort, NewRgn, SetRectRg, CopyRgn, InsetRgn, DiffRgn, DisposeRgn, isValidPort, LocalToGlobal, QDDisplayWaitCursor, HideCursor, ShowCursor, SetCursor

Then for files, FSpGetFInfo. That doesn’t seem too bad.

If I don’t link Carbon.framework and AGL.framework (Carbon OpenGL access) in a working app, there’s about 8 AGL link errors - all of which, AFAIK have CGl equivalents. Suspiciously, there’s no Carbon link errors. Maybe the whole app gets carbon by default.

_aglChoosePixelFormat
_aglCreateContext
_aglDestroyContext
_aglEnable
_aglSetCurrentContext
_aglSetDrawable
_aglSetInteger
_aglSwapBuffers

Bruce

6

A .mm file is Objective C++. It can call Obj C methods in a hybrid style.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_10.html

But more, relevant, there’s a C++ runtime, and it may be easy enough to call Obj-C system functions like this:
// The callback function for when we want to produce a system beep from cocoa.

void BeepFromCocoaCallBack (Widget w, XtPointer client_data, XtPointer call_data) { //Calling the cocoa native function. BeepFromCocoa(); }
Actual Cocoa methods would need to be wrapped:

CFRange CheckSpellingOfString(CFStringRefstringToCheck, intstartingOffset) { NSRange range ={0,0}; NSAutoreleasePool*pool=[[NSAutoreleasePoolalloc]init]; range=[[NSSpellCheckersharedSpellChecker] checkSpellingOfString:(NSString*)stringToCheck startingAt:startingOffset]; [poolrelease]; return(*(CFRange*)&range); }

From: http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/index.html

Bruce[/url]

7

why is objective-c? whats apples reason to use an obscureish lingo?

8

Hi All,

The use of objective C comes from Apple’s acqusition of NextStep.

http://en.wikipedia.org/wiki/NEXTSTEP

It is a truly horrible syntax. :slight_smile:
Typical of Apple to do something completely non-sensible. The whole world is using C++/C, they go and do something completely different. Oh well!

I’ve had to do some mixed-mode programming combining C++ and Objective-C. That was to embed a HTML control in a dialog.

As the interfacing for the HTML could only be done using objective C APIs, I had to create a .mm file, and give C-style exported functions that I could link to from my .cpp code. The bulk of the .mm file was in objective C, apart from those linking functions.

Here is some cleaned-up code to give you the general idea…

//
// Declare a new objective C class to implements a loose interface that
// acts as a delegate for WebFrame events (WebFrame is owned by WebView)...
//

//@interface NSObject (WebFrameLoadDelegate)
@interface MyDelegate : NSObject
{
//    instance variable declarations
}
//method declarations
- (id)init;
- (void)dealloc;

...
... More stuff here
...

@end

...
... More stuff here
...


//
// private_LoadUrlIntoHIView
//
// Tell the web view to load a request for a URL.
//
static void private_LoadUrlIntoHIView( HIViewRef inView, CFURLRef inURL )
{
  WebView*    lpWebView;
  NSURLRequest*  request;
  WebFrame*     mainFrame;

  lpWebView = HIWebViewGetWebView( inView );

  // Get information related to loading!
  //[lpWebView setResourceLoadDelegate:lpWebView];

  MyDelegate *lpMyDelegate = [[MyDelegate alloc] init];
  [lpWebView setFrameLoadDelegate:lpMyDelegate];

  //NSObject *lpCheckedDelegate = 
  [lpWebView frameLoadDelegate]; 

  request = [NSURLRequest requestWithURL:(NSURL*)inURL];
  mainFrame = [lpWebView mainFrame];
  [mainFrame loadRequest:request];
}

//
// Define function with "C" linkage that allows calls to
// private_LoadUrlIntoHIView to be invoked
// from plain C or C++... (private_LoadUrlIntoHIView uses Objective-C...)
//
void LoadURLIntoHIView( HIViewRef inView, CFURLRef inURL )
{
  private_LoadUrlIntoHIView(inView, inURL);
}

I hope that makes some sort of sense. :slight_smile:

Pete

9

So in other words, in response to Jules’ question:

The answer is, yes, you can put the Objective-C wrapping code in a .mm file; you’ll need to provide C-style wrapper functions that your C code can hook-in through.

There is also one compiler flag setting you need to configure with XCode, that allow your project to mix both .mm files and .cpp files.

HTH!

Pete

10

Well, good to know it’s possible, even if it’s a bit of a pain.

11

[quote=“Bruce Wheaton”]Carbon isn’t getting moved to 64 bit. That doesn’t mean you have to use Cocoa, necessarily. If you can move to Core Foundation (CFnnnNnnnn) then that will probably be fine.
[/quote]

This is an important point. It’s only user interface elements, like HIView that apparently won’t get moved to 64bit. This means you can do calculations in 64 bits, but perhaps have more trouble displaying that data. Until we have to deal with soundfile formats that exceed 2GB on a regular basis (Core Audio Format anyone?), I don’t see this as a big problem.

12

Yeah, my understanding is the same, Apple won’t bring any UI APIs includes HIView so that means we can’t use HICocoaView in 64bit Carbon, it’s huge pain…

Even if we have no advantage of 64bit in our application, when someone… for example, Apple releases Logic Pro 8 which runs in 64bit environment, we have to make 64bit version of our plugins. I’ve never seen the professional DAW using Cocoa right now though.

One good thing is JUCE is great, windowing functions are written in ComponentPeer, and almost all platform specific things is written separatedly. I think there is a chance to make it for 64bit Cocoa+Carbon. (It’s hard way though!)

Best regards,
Masanao Hayashi

13

Yes, getting juce to work will definitely be possible, although might involve me doing a lot of typing.

No idea how Apple expect all the big legacy applications to cope with this, though - are Adobe going to rewrite Photoshop in obj-c?!

14

Maybe everyone at Adobe is hoping for someone else to do it, the way we all depend on you :lol:

I say let’s see what really breaks. We know all the get & set port stuff needs to go anyway, but let’s see what really won’t compile. Could be there’s workarounds to get 64 bit for those who really need it. Could be Apple will back off the way they had to with Carbon.

Bruce