On Oct 29, 2007, at 1:13 PM, Jeff Hobbs wrote:
> Kevin Walzer wrote:
>> With Leopard's release, I'm taking another look at Tk Aqua's future.
> ...
>> Although I know Apple has made no official statement about this, it
>> sounds as if Carbon is in the process of being shifted to a legacy
>> API:
>> kept around, but not updated. The signals to shift to Cocoa
>> couldn't be
>> stronger. For me, this is ironic, because I'm learning C and
>> Carbon so I
>> can submit some patches to various bits of Tk that Daniel hasn't had
>> time to work on.
>
> I still find your notes more alarmist than practical in any sense.
What is unrealistic about this picture of the future? Carbon
developers have already needed to use Cocoa in their Carbon
applications to provide certain functionality and now it's only going
get worse. As a result of the announcements at WWDC lot of Carbon
developers are deciding to port their applications to Cocoa, which
leaves even fewer Carbon developers for Apple to accommodate. Fewer
to accommodate means Apple will do even less in the future to
accommodate them, and the obvious end of this cycle is that Carbon
ceases to be a viable technology for building competitive Mac OS X
applications. Eventually Apple will explain how supporting Carbon
just doesn't fit into their long term vision because so few people
are using it, and none for what they consider "top tier" products,
the ones the Mac needs to be a viable platform.
> Apple's changes over time need to be followed, but from reading
> various
> articles, even Cocoa users weren't spared in Leopard,
But at least Cocoa users haven't been told that Cocoa is going to be
allowed to die off, or that future development is going to focus on
something they aren't using.
> and Carbon is far
> from singular to Tk. From the Ars Technica article on Leopard:
>
> """
> In Cocoa, deprecated APIs were simply not ported to 64-bit. The
> Objective-C runtime is all-new for 64-bit, with a new ABI, faster
> dispatching, zero-cost exceptions, and public APIs for introspection
> built on top of newly opaque internal structures. All over Cocoa, ints
> have been replaced with NSIntegers. In all of the graphics APIs,
> floats
> have been replaced with CGFloats.
>
> QuickTime also got the "Carbon treatment." The venerable plain-C
> API for
> QuickTime is not available in 64-bit. The Cocoa QTKit library is the
> only game in town for 64-bit QuickTime.
>
> And on and on. With Leopard, Mac OS X's API future is clearer than
> it's
> ever been. The future is Objective-C, Cocoa, 64-bit. Full stop, no
> waffling, everyone get on board the train.
>
> There's an inherent tension between developers with existing
> applications and skillsets and the OS vendor's desire to attract new
> blood and make good long-term decisions for the platform. The late
> call
> on the 64-bit Carbon decision is clear evidence that Apple struggled
> mightily with these issues internally.
Apple's internal struggles have been more political than anything
IMO. Most of the powers that be at Apple, such as Steve Jobs and
Bertrand Serlet (and Avie Tevanian before him before him) are NeXT
people, and in my experience the NeXT people consider Carbon
developers irrelevant. They see Apple and the Mac as nothing more
than a way to make their beloved NeXT operating system and software
the successful consumer product it failed to be under NeXT Computer.
I suspect the only internal discussions were about how long they
needed to keep stringing the Carbon developers along before deciding
they weren't needed anymore.
> In the end, Apple made the hard choice instead of the easy one.
I don't know how hard it was for them, but it was certainly
unethical. Apple had been telling Carbon developers for years that
Carbon was a viable option for Mac development. A "first-class
citizen" as Steve Jobs put it. They enhanced it in ways that required
Carbon developers to redesign their applications (composited
windows). They got Carbon developers to convert their old dialogs to
Carbon nibs. They promised 64-bit Carbon right up until the moment in
WWDC when a bullet point made it clear they had reneged on that
promise. Now their official stance has changed. As evidence of their
view of the Carbon developers who done so much to provide software
for Mac OS X, Interface Builder will not convert Carbon nibs to Cocoa
nibs, and Apple kept the decision to kill Carbon 64 secret until
WWDC, even while some Carbon developers were working hard to get
their Carbon applications ready for 64-bit Carbon. That decision was
*not* made on the eve of WWDC. Boo Apple.
> I think it will pay off, though the short-term consequences could
> be pretty grim.
It will work. I don't know if it will be a big "pay off." If Apple
had invested the resources they put into modernizing and updating
Cocoa for Mac OS X into Carbon, I think you'd still have as many
compelling Mac OS X applications. That is, I honestly don't think the
average Mac user would see a significant difference. The biggest
difference might be a lot less weekend wonder Cocoa applications that
in my experience aren't that impressive anyway.
> After all, just look at how long it's taking to get an
> Intel-native version of Microsoft Office for the Mac.
The biggest delay in getting an Intel version of Office was probably
the process of porting their CodeWarrior projects to Xcode, which was
delayed even more than normal by the fact that Microsoft initially
found Xcode to not be up to the task, so they had to wait for Apple
to addresses some of the issues they had with it, and they were not
trivial issues.
> Should we expect a
> 64-bit Cocoa version in, say, 2012? And I have no idea what Adobe's
> going to do about 64-bit versions of its products.
The biggest problem for Adobe is plug-ins. Even if they had a Cocoa
version of Photoshop today a lot of Photoshop users wouldn't buy it
because none of their third-party plug-ins would be compatible with
it. I seem to recall hearing that internally they have a Cocoa
version of Photoshop, but the plug-in issue is a show stopper for the
foreseeable future.
Just my $0.02.
Larry
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/_______________________________________________
Tcl-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac