Let's look at this in a slightly different way. Apple
introduced the Intel Macs which now run Windows
alongside MacOS X. The net effect is that Apple is
stating that if they can't beat them, join them. I'm
sitting here running my IC design software under
Windows while I'm doing my email in MacOS. I love the
dual environment because it allows me to run
everything at the same time. I really like running
Windows and MacOS at the same time. Now, what would be
better than being able to build an application for
Windows and MacOS using nearly identical API's? Think
about it, an environment where Windows coding and Mac
coding aren't all that different...and what do you
get? Carbon, not Cocoa. I'm no big fan of Windows, but
it is a necessary evil for the technical work I do for
a living. The design tools I use dont' exist under
MacOS and never will - I'm stuck in Windows until the
day I retire from the technology ratrace. I can't help
but think that if the MacOS GUI wasn't such a
stumbling block, maybe I could actually talk some of
my tool vendors into porting their apps to MacOS. The
mere mention of this brings laughter to most of them
with a comment that they don't have the resources
necessary to do such a different sort of GUI. But
they're porting all of their tools to Linux without
hesitation. So now I'll run Linux and Windows and
MacOS all at the same time to get all the different
apps that I want. The fact that porting to Linux is
something these vendors will do while rejecting MacOS
ports means it's not worth the time and money to do
it. I don't see how pushing carbon into the background
in favor of Cocoa is going to convince developers to
port their apps to MacOS. If anything, I see Cocoa as
a barrier to entry for most of these tool vendors...
Just my two cents as a dumb user of obscure nerdy
tools...
Tony
--- Laurence Harris <email@hidden> wrote:
>
> On Jun 13, 2007, at 8:56 PM, Dave Camp wrote:
>
> >
> > On Jun 13, 2007, at 5:40 PM, Tony Scaminaci wrote:
> >
> >> Carbon was intended as a transitional API from OS
> 9 to OS X and it
> >> worked well for that purpose. Carbon's been
> around since the
> >> advent of OS X so how long do you keep a
> transitional API alive?
> >> The problem here is that the replacement API
> (Cocoa) is nothing
> >> like carbon and as Larry has said, it's much more
> than just an
> >> API. It's an entirely different philosophy of
> programming and one
> >> that is not cross-platform. Hind sight is 20/20
> but maybe a better
> >> thing to do would have been to develop an API
> similar to Windows
> >> (heretic!!!) given the fact that we're now
> transitioning to Intel
> >> anyway. If Apple had done that instead of ramming
> Next's Cocoa API
> >> into XCode, maybe we'd all be better off as Apple
> developers
> >> today. The way to keep the Mac viable is for
> software that people
> >> run under Windows to also run under OS X. The
> stumbling block has
> >> been Cocoa because it's so different.
> >
> > I've seen several statements in this thread to the
> effect of Cocoa
> > "is not cross-platform", thus it's bad.
>
> I don't think they've said it's bad, but just that
> it's not the
> direction they want to go.
>
> > I fail to see how this is relevant to the subject
> at hand: no 64
> > bit Carbon UI code in Leopard. If you are writing
> native Mac OS X
> > UI code, it's platform specific by definition
> regardless of which
> > language or API you use.
>
> True, but I think the problem as people perceive it
> is that the
> Carbon programming model is closer to the Windows
> programming model
> than Cocoa, and hence it's easier to develop
> cross-platform
> frameworks with Carbon than with Cocoa. There's also
> the issue of
> needing to use Objective-C to use Cocoa instead of
> using a cross-
> platform language like C or C++.
>
> I'm sure you understand that perception is
> everything, and if you're
> in the group that does the Mac version of a Windows
> application and
> the Windows people are running the show, they may
> not see the need to
> use Cocoa in the same light you do.
>
> Larry
>
> _______________________________________________
> Do not post admin requests to the list. They will be
> ignored.
> Carbon-dev mailing list
> (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
