Kristoffer Lawson wrote:
>  
>  
>  I can't really see the benefit in holding on tight to Carbon.  
>  Besides, purely from a user's perspective, Cocoa application in  
>  general feel more refined.
>  
>  

I've had kind of the opposite experience. Cocoa doesn't follow all of
Apple's human interface guidelines (for example, push buttons are too wide
in Cocoa), and a lot of Cocoa developers get lazy. If Cocoa provides the
desired behavior automatically, great. If it can't, that generally means a
good bit of work so a lot of Cocoa developers won't spend the time needed to
do things right in the edge cases. Cocoa also tends to be slower than
Carbon. I remember when I first heard about Delicious Library. It was
supposed to be this super-slick Cocoa application. So I tried it. It was dog
slow, and one thing that stuck out like a sore thumb was that it had menu
commands that were always enabled and never did anything. These were
standard commands that Interface Builder adds automatically but weren't
really applicable to that application. The developer should have removed
them. It's easy to do, but he just didn't bother. That's not the kind of
stuff you find in "refined" applications.

There certainly are some very slick Cocoa applications out there, but there
are lots of them that aren't so slick.

FWIW, both Xcode and Interface Builder are Cocoa applications and neither
one strikes me as refined.


As for holding on to Carbon:


- The death of the Mac OS. The loss of Carbon over time basically represents
the completion of the transition from Mac OS to NeXTStep. Cocoa, the Unix
underpinnings, the Dock, Xcode (formerly Project Builder), Interface
Builder, and some other things are all straight out of NeXT. The problem
with this is that we're getting more and more developers who really don't
understand Mac software and losing more and more who do. Real Mac software
is not just software that runs on a Mac. It follows certain guidelines.
There is consistency across applications. It's forgiving of mistakes and
less demanding in its requirements of the user. When I first tried to
install the Safari 3 beta, the installer said none of my volumes met the
requirements. Turns out it was because I had Safari in a folder inside my
Applications for instead of in the Applications folder itself. The first
time I tried an iDVD tutorial iDVD couldn't find it, even though the
tutorial resides inside the iDVD bundle itself. Turned out to be the same
problem: iDVD wasn't in the Applications folder itself. Before Mac OS X I
never had those knds of problems, but Cocoa applications are more path
dependent than traditional Mac applications. There's nothing refined or
elegant about rigid path dependence.

- Integrity. Apple told Carbon developers that Carbon would continue to be a
"first-class citizen" for Mac development. They told developers at WWDC 2006
they would have 64-bit Carbon. Carbon developers were crucial to the success
of Mac OS X in the early days. Without Carbon applications Mac OS X would
never have succeeded. Now that Mac OS X is well established and there are
more Cocoa developers and applications out there, apparently Apple thinks
it's okay to cut off the people on whom they relied in the past. Had Apple
told people up front that Carbon was only a transitional technology that
would be deprecated at some point Mac OS X may not have had enough software
to make it viable as a platform when it premiered. Speaking as a Carbon
developer with some 15 years of experience in Mac application development, I
feel used.

- Loss of software. There *will* be applications that go away over time as a
result of this change. Many of them will be cross-platform applications done
by companies that would rather just kill the Mac version of a product than
rewrite it for Cocoa. Some Carbon developers will leave simply because
they've already spent too much time rewriting existing applications to stay
up with the Apple's latest changes. Every time Apple dumps a transtion on
its developers they have to spend time -- sometimes months or more --
rewriting applications to get virtually the same application they had
before, and you can't really sell that. Suppose you have a Carbon
application, and the developer rewrites it for Cocoa. How much of an upgrade
fee would you be willing to pay if the only thing different about the new
version is that it's Cocoa? Not much I dare say.

-- 
View this message in context: http://www.nabble.com/No-64-bit-Carbon-%3D-Problem-for-Tk-Aqua
--tf3935997.html#a11281897
Sent from the tcl-mac mailing list archive at Nabble.com.