Originally Posted by Snafu
Yes, that is so, but it is easier to map multiplatform UI features to Carbon or create new ones based on it, and that avenue is closed for 64bit.
Hmm. I'm not sure I agree with that. In fact, I'm pretty sure I don't, as a blanket statement. Carbon may feel more familiar to someone coming from Win32 or an X environment, but that's because it's similarly a legacy design. Callbacks, resource maps, and all those things we all thought were so slick 20 years ago are kind of outdated these days.
Furthermore, if someone ports their UI from another platform to the Mac, and expects to be able to just slip in some Carbon-style callbacks, calls, and so on into their other-platform UI, and have it work, well... it'll *work*, but it's going to look like *ass*. Mac users will notice, even if no one else does. If you want to play in the Mac sandbox professionally you need to step up and create a *Mac UI*. That's all there is to it.
Given that constraint, the UI code is likely to be very Mac-specific, even if it Carbon. The cross-platform argument goes out the window at the UI level, for any serious developer's app, if you ask me. Back-end? Sure! Knock yourself out. Build up those C and C++ libraries for all platforms - I do it that way too. But there's no reason why a Cocoa UI can't call into them just like a Carbon UI.
When most comments talk about separating the program's logic from the program's UI, they seem to assume that the UI is the easy part, and that's not necessarily so, when one considers, say, Maya's UI or After Effects'. Cocoa won't cover for their needs in a straightforward way.
This is quite true. UI design is a pain in the butt, which is why so few developers manage to get it right, or even in the ballpark.
Anyway, it feels a bit forced to do a "what was Adobe thinking all these years", as if it was so easy peasy a porty: how many gigantic apps is CS3 composed of? A dozen or so, plus a inmense community of plug-in developers which will have to rewrite (again!) their products (we'll see how many we lose this time). It's not trivial, it was even less so in the past, and they gain nothing but 64bitness and a big headache testing and reoptimizing things.
No one said it was easy, but that it was necessary... and no one expected it to be fast, which is why there was a what, *9 year gap* between "Carbon is for legacy code" and "By the way... we're not bringing Carbon forward to 64-bit." The writing has been on the wall every since Carbon and Cocoa were unveiled. I think a decade is enough time for everyone to get the hint and prepare their plans, don't you?
Of course. They don't have much choice.
How many pro apps has Apple ported from Carbon to Cocoa? Do they intend to port any, actually? One suspects we'll see the Pro Apps UI toolbox inherit what's left of Carbon64's development and so sidestep the issue.
That's an interesting idea, and a possibility. Kind of underhanded if so, but I'm betting that they'll be Cocoa up top.
Remember, as the years have progressed, most of the Carbon functionality has been pulled out of Carbon and put in Core*, which Carbon then calls. And so does Cocoa. *Most* of what devs expected in Carbon should still be available, just through a different API. Not all of it, obviously, but they get a lot of other things for free instead.
I'll be interested to see that list of apps that are Carbon, Cocoa, and when they changed over.