Re: Cocoa and future
Re: Cocoa and future
- Subject: Re: Cocoa and future
- From: Jens Alfke <email@hidden>
- Date: Fri, 20 Feb 2009 08:51:27 -0800
On Feb 20, 2009, at 8:35 AM, john smith wrote:
But it's more than that (and please excuse me if I'm wrong in the
following, because I'm just starting to look into this): First I
need to learn obj-C, in order to implement the view. Then I need
some way for that view to communicate with my C++ code. Then that C+
+ code need to communicate with some other cocoa code, because
drawing functions no longer are support in carbon.
So, basically I'll be using a fair amount of time setting up a
system which translates from A to B to A, and I even have to learn
language A... all this, just to be able to do what I'm already doing.
You lost me with "A to B to A". You need to implement an NSView
subclass in Obj-C, which will contain a few methods to do the drawing
and handle events. The drawing method will probably boil down to a
single CoreGraphics call. The event handlers will massage the event
parameters and make a C++ call into your code. You'll also need a C/C+
+ function to be called from the cross-platform code to update the
view, which will just call [view setNeedsDisplay: YES] to make the
view redraw. And of course you need another C function to initialize
the view.
That sounds pretty much like what you're probably already doing with
Carbon, except you're using Cocoa APIs instead. It's not any more
awkward or convoluted. It does mean using some APIs you're unfamiliar
with, but that's a pretty common and regular occurrence in our field :)
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden