Re: Cocoa and future
Re: Cocoa and future
- Subject: Re: Cocoa and future
- From: tahome izwah <email@hidden>
- Date: Fri, 20 Feb 2009 18:03:27 +0100
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