I was running along the lines that if Cocoa uses Carbon to handle events, and Cocoa is not usable on any other platform, why not use Carbon directly, as the Wacom guys provide examples for using both.  It is not that I am scared of ObjC, it is having to base the entire external in ObjC and then it has to be completely rewritten for all other platforms. 

I think the only real motivation I had behind using Cocoa was to learn it, along with ObjC.  I thought compatibility would be another reason, but I am not so sure any more. 

Another related question for those more experienced then myself: can I have the base of the external in C, then call methods from another source file containing the Cocoa API in ObjC?


2009/12/23 IOhannes zmölnig <zmoelnig@iem.at>
Rich E wrote:
> Hmmm, after hearing back from the Cocoa-dev mailing list that all of Cocoa's
> Event handling code is based on Carbon (and is 64-bit compatible, at least
> the Event Handling), I don't know if it is worth it to write the external in
> ObjC (which I will probably do poorly at that, as it is my first attempt
> with the language).  Anyways, Carbon is written in C, the WinTab API is
> written in C, so introducing ObjC may turn out to be a hassle later on
> instead of allowing future compatibility?

??
just because cocoa uses carbon as a backend for event handling this
shouldn't scare you away from using ObjC. most low-level runtime
libraries, are written in C - but it still makes sense to use a higher
language (if it makes sense) to use them.

ObjC is mostly a macOS thing; cocoa/carbon is obviously macos only.
if you want crossplatform, then you shouldn't use it.
if you want "native" macos support, it's a good choice (imho).

learning a new language can still be fun.

fg,arsd
IOhannes