Moribund Carbon...any thgouths

[Kevin Walzer-5]

With Leopard's release, I'm taking another look at Tk Aqua's future.

John Siracusa's take on the future of Carbon strikes me as pretty apt
(see http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6). Here it is,
in a nutshell:

"Yep, it's (finally) the end of the line for Carbon GUI applications in
Mac OS X. Oh, sure, they'll be around for years and years to come, but
the lack of 64-bit support is a long-term death sentence. The last
vestiges of the original Macintosh API are finally being put to rest.
They've done their job and are being given a decent burial, I think. A
slow, almost natural transition. Bugs will be fixed in the 32-bit Carbon
APIs, of course, but no new features will be added. All new GUI APIs in
Leopard and future Mac OS X releases will be added as Cocoa-only APIs."

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 can live with Carbon being moribund, but I hope Apple doesn't
proactively break it at some point in the future...given their history,
however, it's likely they will.

Thoughts?

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

-------------------------------------------------------------------------
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

[Jeff Hobbs]

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.
Apple's changes over time need to be followed, but from reading various
articles, even Cocoa users weren't spared in Leopard, 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.

In the end, Apple made the hard choice instead of the easy one. I think
it will pay off, though the short-term consequences could be pretty
grim. After all, just look at how long it's taking to get an
Intel-native version of Microsoft Office for the Mac. 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. That's many millions
of lines of Carbon code between those two companies alone. We may be in
for a rough patch, so buckle up.
"""

Jeff

-------------------------------------------------------------------------
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

[skytag]

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

[Daniel A. Steffen]

On 30/10/2007, at 4:13, Jeff Hobbs wrote:

> Kevin Walzer wrote:
>> With Leopard's release, I'm taking another look at Tk Aqua's future.
>
> I still find your notes more alarmist than practical in any sense.
> Apple's changes over time need to be followed, but from reading  
> various
> articles, even Cocoa users weren't spared in Leopard, and Carbon is  
> far
> from singular to Tk.

indeed, IMO there is no immediate cause for alarm, Carbon is certain  
to be around for a long time yet even if it is now in maintenance  
mode (i.e. no new features). Just look at QuickDraw, that has  been  
deprecated essentially since 10.0 and we're still using it in Tk in  
Leopard today (even though our dependency on it is much reduced by now).
We don't particularly need any of the new features that have been /  
are being added to other frameworks, most are not very applicable to  
Tk as a cross-platform toolkit anyway (e.g. how would you integrate  
CoreAnimation into Tk in a way that made x-plat sense?)
The main thing that we loose in the short term by the remaining  
reliance on HIToolbox in Tk is the ability to run as 64bit, it's not  
clear to me that this is crucial in the immediate future...
Note that many of the Carbon APIs that we use are in fact available  
in 64bit on Leopard, such as Carbon event handling, HITheme & more,  
and these are not likely to disappear (e.g. Cocoa event handling is  
based on Carbon events).
The problem areas are essentially the same as always: native widgets  
(i.e. not Ttk) and window (toplevel) handling.
These were bits that were going to have to be ripped out and replaced  
anyway in a move to HIView & compositing mode; now that HIView is  
deprecated, the move will have to be to NSView instead...
The main challenge with both moves is to figure out how to integrate  
Tk's X11 style of drawing at idle time in response to Expose events  
with the HIView/NSView model where the OS tells you when you can draw  
and passes in the drawing environment to use (the only way to get a  
CGContext for drawing in this model is inside a draw event handler  
resp. drawRect method). There is no concept of an update event in  
this environment, and currently I see no practical way to synthesize  
Expose events that doesn't involve massive hacks.
The best way forward may well be generic Tk reform to rely less on  
low-level X11 details and use a higher level abstraction that can  
encompass both styles of drawing...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **



-------------------------------------------------------------------------
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

[Kevin Walzer-5]

Daniel A. Steffen wrote:

>
>
>
> indeed, IMO there is no immediate cause for alarm, Carbon is certain to
> be around for a long time yet even if it is now in maintenance mode
> (i.e. no new features). Just look at QuickDraw, that has  been
> deprecated essentially since 10.0 and we're still using it in Tk in
> Leopard today (even though our dependency on it is much reduced by now).
> We don't particularly need any of the new features that have been / are
> being added to other frameworks, most are not very applicable to Tk as a
> cross-platform toolkit anyway (e.g. how would you integrate
> CoreAnimation into Tk in a way that made x-plat sense?)
> The main thing that we loose in the short term by the remaining reliance
> on HIToolbox in Tk is the ability to run as 64bit, it's not clear to me
> that this is crucial in the immediate future...
> Note that many of the Carbon APIs that we use are in fact available in
> 64bit on Leopard, such as Carbon event handling, HITheme & more, and
> these are not likely to disappear (e.g. Cocoa event handling is based on
> Carbon events).
> The problem areas are essentially the same as always: native widgets
> (i.e. not Ttk) and window (toplevel) handling.

Apple has made a pretty reassuring statement about Carbon's future here:

http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/PortingTo64Bit/chapter_4_section_5.html#//apple_ref/doc/uid/TP40004381-CH3-SW2

In essence, 32-bit Carbon isn't going anywhere.

(Chicken Little sheepishly goes back to coding...)

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

-------------------------------------------------------------------------
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