Carbon and Cocoa
- Thread starter leojose
- Start date
Lt Major Burns
"Dicky" Charlteston-Burns
i'm not sure that it's that direct. Carbon was apples way of describing programming that was basically the same as in the pre-unix, Classic environment, but had been reconfigured to run natively in OSX
Cocoa is completely native to OSX, and has no left over relation to the old Classic days.
Carbon is old, but familiar and compatible, Cocoa is new, modern and powerful.
iTunes and the Finder are still carbon, things like iPhoto, messenger and Garageband are in cocoa.
characteristics of cocoa are that cocoa will respect the placement of the dock, and resizing using the + button actually works. also the Application menu is more contextual.
i'm not an actual programmer, so i'm going to get corrected.
Cocoa is completely native to OSX, and has no left over relation to the old Classic days.
Carbon is old, but familiar and compatible, Cocoa is new, modern and powerful.
iTunes and the Finder are still carbon, things like iPhoto, messenger and Garageband are in cocoa.
characteristics of cocoa are that cocoa will respect the placement of the dock, and resizing using the + button actually works. also the Application menu is more contextual.
i'm not an actual programmer, so i'm going to get corrected.
Viro
Registered
Carbon is a library, which is very similar to Win32 (i.e. Windows) code. It is what most cross platform applications use, since as Lt Major Burns says, it is more familiar to developers. You can call it from C, C++, and probably other languages. That said, it is _not_ a language.
Cocoa is a library that is usable from Objective-C or Java. It's more 'modern', and kinda integrates better with the OS. Things like automatic spell checking in a text box (like the one I'm typing in now) are only available in Cocoa apps, not Carbon. This is just one example of how Cocoa seems better integrated into the OS. The 'look' of Cocoa applications adheres better to the OS X guidelines, mainly because the changes to the OS X interface (for some reason) do not always apply to Carbon applications.
If you want to port a C++ application from Windows, you will most likely want to concentrate on Carbon. However, I have a better suggestion. Since you are talking about bringing a C++ application over from Windows, the chances are high that it is written in MFC. If it is, you should stay away from Carbon and Cocoa. Instead you should us wxWidgets. It is similar to MFC, and it is cross platform, running on anything from Palm OS, to OS X.
wxWidgets is a good option because it actually uses native controls and doesn't emulate them, like Qt or Java Swing does. The benefit of that is your app looks great, and behaves great too
. On OS X, you even have the option of using either Cocoa or Carbon controls.
So if you are thinking of porting a Windows C++ app that was written using MFC, you really must look at wxWidgets. For a moderately sized application (approx 10,000 lines), you may even get it ported in under a day.
Cocoa is a library that is usable from Objective-C or Java. It's more 'modern', and kinda integrates better with the OS. Things like automatic spell checking in a text box (like the one I'm typing in now) are only available in Cocoa apps, not Carbon. This is just one example of how Cocoa seems better integrated into the OS. The 'look' of Cocoa applications adheres better to the OS X guidelines, mainly because the changes to the OS X interface (for some reason) do not always apply to Carbon applications.
If you want to port a C++ application from Windows, you will most likely want to concentrate on Carbon. However, I have a better suggestion. Since you are talking about bringing a C++ application over from Windows, the chances are high that it is written in MFC. If it is, you should stay away from Carbon and Cocoa. Instead you should us wxWidgets. It is similar to MFC, and it is cross platform, running on anything from Palm OS, to OS X.
wxWidgets is a good option because it actually uses native controls and doesn't emulate them, like Qt or Java Swing does. The benefit of that is your app looks great, and behaves great too
. On OS X, you even have the option of using either Cocoa or Carbon controls.So if you are thinking of porting a Windows C++ app that was written using MFC, you really must look at wxWidgets. For a moderately sized application (approx 10,000 lines), you may even get it ported in under a day.
Mikuro
Crotchety UI Nitpicker
Actually, Cocoa is based around Objective-C, not C++. Carbon is built for C and C++, and if you're porting from Windows, you'll probably find it easier to work with Carbon.
That said, there are definite advantages to working with Cocoa, and if a lot of your logic is already written in C++, that's okay, because you can mix C++ into your Cocoa/Objective-C programs pretty seamlessly (this hybrid language is called Objective-C++).
Most of what Burns said is true, at least in practice. Cocoa apps are usually much cleaner and more "OS X-like". Most of the time you CAN mimic in Carbon the functionality normally associated with Cocoa, but few programmers do, because it takes a lot of extra work, whereas in Cocoa, you get it all "for free".
That said, there are definite advantages to working with Cocoa, and if a lot of your logic is already written in C++, that's okay, because you can mix C++ into your Cocoa/Objective-C programs pretty seamlessly (this hybrid language is called Objective-C++).
Most of what Burns said is true, at least in practice. Cocoa apps are usually much cleaner and more "OS X-like". Most of the time you CAN mimic in Carbon the functionality normally associated with Cocoa, but few programmers do, because it takes a lot of extra work, whereas in Cocoa, you get it all "for free".
I really like all your suggestions...
Viro : I had a look at wxWidgets website it seemed to be pointing towards developing GUI based applications.
I quote from its website
Do you still believe wxWidgets is a good option?
Viro : I had a look at wxWidgets website it seemed to be pointing towards developing GUI based applications.
I quote from its website
My application deals with networking (TCP,UDP). There are a few MFC dlls also but its a 'background' application with lots of threads.
Do you still believe wxWidgets is a good option?
lurk
Mitä?
Sure lots of them. What are you trying to do? If this is really a background task then you could just target the BSD layer and basically get Unix/Linux compatibility for free.
It really depends on what you need. Files and networking -- BSD is you friend. Interfacing with the Keychain and Authorization Services -- you will need to use Objective-C and Core Foundation (if you value your sanity). Also keep in mind that you are free to mix and match C, C++, and Objective C along with BSD, Carbon and Cocoa. So it might be best to just write a Objective C interface to the services you need and then call that from the existing C++ code.
I guess the overall point is that you can do it almost any way you would like and you have not given enough information to identify if one way is actually going to be better than another in this situation.
Good Luck!
It really depends on what you need. Files and networking -- BSD is you friend. Interfacing with the Keychain and Authorization Services -- you will need to use Objective-C and Core Foundation (if you value your sanity). Also keep in mind that you are free to mix and match C, C++, and Objective C along with BSD, Carbon and Cocoa. So it might be best to just write a Objective C interface to the services you need and then call that from the existing C++ code.
I guess the overall point is that you can do it almost any way you would like and you have not given enough information to identify if one way is actually going to be better than another in this situation.
Good Luck!