Re: Cocoa and future
Re: Cocoa and future
- Subject: Re: Cocoa and future
- From: Richard Burnett <email@hidden>
- Date: Fri, 20 Feb 2009 15:07:42 -0500
Talk about the flip side of the coin, a few years I go I began writing an AudioUnit plugin and had happily implemented quite a bit of it, in Cocoa, when I decided, hey, I'll try this with Digital Performer. At that time, DP would only show Carbon based plugins. I thought, okay, well then I will just make this in Carbon then. After spending a few days looking through the sample code and beginning the work on it, I said forget it. To me, the extra work and coding required gave me flashbacks to the days of programming with the Win32 api....shudder! :)
I felt the ramp up to Objective-C coding was WAY shorter than the slow incline to when I first learned C++
Rick
Asylum Studio Productions
On Friday, February 20, 2009, at 12:03PM, "tahome izwah" <email@hidden> wrote:
>Yes, and this makes sense (to some extent).
>
>Bear in mind though, it's only 5 lines of Cocoa code to draw
>everything into a bitmap and swap that to the screen, so there is no
>need to start a Cocoa vs. Carbon thread over this. If you want
>instructions on how to do this email me off the list, I'd be happy to
>send you a project that subclasses NSView and draws stuff into a
>bitmap.
>
>Developers are always afraid of things that have a learning curve
>because they are, by nature, convenient people (myself being no
>exception to this). However, once they bite the bullet and delve into
>something new they rarely want to look back (which is the flip side of
>the same coin, I guess).
>
>Even if it seems like more work in the short term (which it is, and I
>felt the same way about it) you'll thank us for making yo go through
>this as Cocoa will save you so much work further down the road... :-)
>
>--th
>
>
>2009/2/20 john smith <email@hidden>:
>>
>>> If you see Cocoa as more of a pain than Carbon, that's just the
>>> learning curve you're looking at. It is much, much more efficient for
>>> writing GUI code than HLTB. (I spent 12 years programming the Classic
>>> OS, then learned Cocoa and never looked back.)
>>>
>>> I don't see why the cross-platform issues are any greater. Both Carbon
>>> and Cocoa are Mac-specific APIs. Both of them can call into cross-
>>> platform code just fine. If your cross-platform code base is in C++,
>>> just use Objective-C++ (.mm files) for your Cocoa code and it can work
>>> with C++ without any problems. (The last project I did for my previous
>>> employer was cross-platform and involved just this kind of setup, with
>>> cross-platform C++ interfaced to Obj-C.)
>>
>> Ok, I *really* don't want to go into a discussion about this, because I know
>> how such discussions can evolve (and it's not always pretty :-)).
>> What I will do however, is try to answer your question, and explain my
>> point-of-view. If you have any questions, please ask, but let's not get into
>> an argument about this, ok?
>> The way I code plug-ins is that I have as few OS calls as possible.
>> Everything is rendered to a buffer, which is then "bitblittet" to the
>> screen. This means that in order to support any given platform, I generally
>> need the following:
>> 1: Some way to paint my buffer in the window
>> 2: Some way to react on mouse and keyboard messages
>> 3: Some non-gui stuff, like file handling
>> That's it. There's some details and variants, but I don't think there's any
>> reason to go into this.
>> So, you see, I've done this for carbon, and I won't have to do it again for
>> any project. Except that I need to do it in cocoa now, so already here it's
>> extra work.
>> 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.
>> Do you see what I mean? There's absolutely no gain for me in cocoa, only
>> extra work. Nothing of what I do on a daily basis uses the OS calls, so it
>> doesn't matter if they're a hassle... If they are an obstacle, then they're
>> an obstacle that I've already crossed..
>> I hope this makes sense...
>> All the best,
>> Michael Olsen
> _______________________________________________
>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
>
>
_______________________________________________
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