Cocoa or Carbon ?

In article <fl6tg0h24ta1bv6e8c1fpaiffvgqb5bgmr DeleteThis @4ax.com>,
Lothar Scholz <dummy DeleteThis @scriptolutions.com> wrote:

 > 2) I have also Win/Linux versions based on the FOX Toolkit.
 > So i must write a common infrastructure layer first -
 > the win/linux is about 40000 lines - this layer is responsible
 > for the handling of events and providing very basic infrastructure
 > like show/hide windows, menu handling, drawing my own
 > controls, handling buttons clicks etc.

You'll probably find that doing your own event handling is easier if you
use Carbon. You can keep Carbon from automatically handling events for
you (thereby letting your common layer handle them), but that's a lot
harder to do with Cocoa. One of the great things about Cocoa is that it
does so much for you, but that's not quite what you're looking for here.

-Eric

--
Eric Albert ejalbert DeleteThis @cs.stanford.edu
<a style='text-decoration: underline;' href="http://rescomp.stanford.edu/~ejalbert/" target="_blank">http://rescomp.stanford.edu/~ejalbert/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

Lothar Scholz wrote:
 > i now got two small "Hello Worlds" programs up and running, one with
 > cocoa and one with carbon. But now i must decide which framework is
 > the best for my purpose. [...]
 >
 > So if you have to write such a thing what framework would you use ?
 >
 > It looks like i can do everything with Carbon, but i'm not sure about
 > Cocoa. Do both of them cover all apple features ?

yes, you can get at everything in both frameworks. however, there seem
to be certain apis that are better represented in one framework or the
other. it's not uncommon for a mostly-cocoa app to use a few carbon
apis, or a mostly-carbon app to use a few cocoa apis.

i'd say that cocoa has the slight advantage here. cocoa apps tend to
feel more macosx-native, carbon apps tend to feel like something left
over from macos9. that's just a bias though, i suspect it's possible to
write native-feeling apps with carbon. it's just that most of the
people using carbon are those who came to macosx from macos9, and they
bring their macos9 habits with them.

 > Which one is easier to wrap into an abstract C layer ?

probably carbon, as it is a c-based api. cocoa uses objective-c, and
that language has a bunch of interesting features that are very
cumbersome to duplicate in a c api, maybe even impossible.

having said that, personally i'd still go with cocoa. i gave carbon a
try for a month or two, and i found it to be the most infuriating api
i've ever used in my life. it's got decades-old cruft that should have
been removed ages ago, but no, they just kept adding new cruft on top of
the old cruft, version after version. personally i'd switch to linux
before i'd program anything in carbon.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

In article <fl6tg0h24ta1bv6e8c1fpaiffvgqb5bgmr.RemoveThis@4ax.com>,
Lothar Scholz <dummy.RemoveThis@scriptolutions.com> wrote:

 > Hello,
 >
 > i now got two small "Hello Worlds" programs up and running, one with
 > cocoa and one with carbon. But now i must decide which framework is
 > the best for my purpose.
 >
 > This is not easy because
 >
 > 1) My application is written with GNU Eiffel.
 > This compiler works perfect on MacOSX.
 > I need to write a C layer around the system calls and then
 > call this c layer from Eiffel.
 >

Have you seen: <a style='text-decoration: underline;' href="http://www.maceiffel.com/" target="_blank">http://www.maceiffel.com/</a>

Their website says they have:

* EiffelCocoa
A complete Eiffel API to Cocoa.
* EiffelCarbon
A comprehensive library for writing fully fledged Mac applications. This
is a library of over 100 classes which provide an Eiffel OO wrapping to
most common Mac toolbox entities. It also provides an event driven
application framework.


So it looks like you may not need to write any wrappers or anything....<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

Jøhnny Fävòrítê (it means "halo, then resonate") <this.is DeleteThis @fake.com> writes:

 > i gave carbon a try for a month or two, and i found it to be the
 > most infuriating api i've ever used in my life. it's got
 > decades-old cruft that should have been removed ages ago, but no,
 > they just kept adding new cruft on top of the old cruft, version
 > after version.

Note that Carbon itself is relatively recent. Its event handling
mechanism, for example, is complete different from the original way.
Many of the functions available, of course, are decades old, but
that's the price of compatibility, and doesn't necessarily make them
bad.

I think Carbon is a perfectly usable API. The only doubt I have is
how well implemented it is. This doubt started the first time I saw a
Carbon call stack while debugging memory leaks. It's also a legacy
API, so while it is unlikely to disappear any time soon, because many
important applications use it, it's equally unlikely that many new
features will be added. One problem that I saw when I looked at Cocoa
is that some of the more useful Cocoa views have no equivalents in
Carbon.

Personally, I think the correct answer to "should I use Carbon or
Cocoa?" is "yes". Both are important, because sometimes you will want
to use a feature that's only available in the other.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

In article <86y8ktoxdq.fsf.TakeThisOut@ed.com>, rhsu.TakeThisOut@ed.com (Robert Hsu) wrote:

 > Note that Carbon itself is relatively recent. Its event handling
 > mechanism, for example, is complete different from the original way.

Actually, the old event handling mechanism is also available if you
still want to use it.

 > I think Carbon is a perfectly usable API. The only doubt I have is
 > how well implemented it is.

Quite well, at least in my opinion. :) That's not to say it's bug-free,
of course, but the engineers who work on it really know what they're
doing.

 > It's also a legacy
 > API, so while it is unlikely to disappear any time soon, because many
 > important applications use it, it's equally unlikely that many new
 > features will be added. One problem that I saw when I looked at Cocoa
 > is that some of the more useful Cocoa views have no equivalents in
 > Carbon.

Carbon has picked up significant new features in every version of Mac OS
X. While that might stop someday, there's no reason to think that it
will. :) Also, there are some Carbon views that don't have equivalents
in Cocoa. Apple's slowly rectifying this over time in both directions.

-Eric

--
Eric Albert ejalbert.TakeThisOut@cs.stanford.edu
<a style='text-decoration: underline;' href="http://rescomp.stanford.edu/~ejalbert/" target="_blank">http://rescomp.stanford.edu/~ejalbert/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

In article <ejalbert-EA9546.20403405082004@localhost>,
Eric Albert <ejalbert.TakeThisOut@cs.stanford.edu> wrote:
 >In article <86y8ktoxdq.fsf.TakeThisOut@ed.com>, rhsu.TakeThisOut@ed.com (Robert Hsu) wrote:
 >
  >> Note that Carbon itself is relatively recent. Its event handling
  >> mechanism, for example, is complete different from the original way.
 >
 >Actually, the old event handling mechanism is also available if you
 >still want to use it.

Carbon Events, however, doesn't eat CPU when the app is idling,
whereas the old way does.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

In article <yNGdnVWmWLyYbY7cRVn-jQ.RemoveThis@speakeasy.net>, Matthew Russotto
<russotto.RemoveThis@grace.speakeasy.net> wrote:

 > Carbon Events, however, doesn't eat CPU when the app is idling,
 > whereas the old way does.

That's true only if you pass a small sleep time to WNE. Pass a sleep
time of MAX_LONG to WNE and you won't waste any more cycles than RAEL
does.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

On 6 Aug 2004 01:42:22 GMT, rhsu.DeleteThis@ed.com (Robert Hsu) wrote:

 >
 >Jøhnny Fävòrítê (it means "halo, then resonate") <this.is.DeleteThis@fake.com> writes:
 >
  >> i gave carbon a try for a month or two, and i found it to be the
  >> most infuriating api i've ever used in my life. it's got
  >> decades-old cruft that should have been removed ages ago, but no,
  >> they just kept adding new cruft on top of the old cruft, version
  >> after version.
 >
 >Note that Carbon itself is relatively recent. Its event handling
 >mechanism, for example, is complete different from the original way.
 >Many of the functions available, of course, are decades old, but
 >that's the price of compatibility, and doesn't necessarily make them
 >bad.

The reason why i think i go with this is that almost all free language
bindings and portable plattform tools use Carbon for implementation.
So i think it's easier to take this reference material instead of
doing everything on my own.

 >I think Carbon is a perfectly usable API. The only doubt I have is
 >how well implemented it is. This doubt started the first time I saw a
 >Carbon call stack while debugging memory leaks. It's also a legacy

This could be a problem. Apple's computers in the low end sector
(eMac/iMac) are very very slow for todays technology. So this might be
a problem for me. But on the other hand i think in terms of two or
three years for my port. And then at least a 1.25 GHz may be usual.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

On Sat, 07 Aug 2004 11:28:57 +0200, Lothar Scholz
<dummy.TakeThisOut@scriptolutions.com> wrote:

 > This could be a problem. Apple's computers in the low end sector
 > (eMac/iMac) are very very slow for todays technology. So this might be
 > a problem for me. But on the other hand i think in terms of two or
 > three years for my port. And then at least a 1.25 GHz may be usual.

The latest eMac/iMac are both over 1GHz now. And of course the
Mac chips are effectively equivalent to a PC chip of about twice
the speed(*)(some would say more!). If you really need more grunt
than that then it must be a very heavy program indeed!

(*)My personal experience is my 600MHz iBook which processes DV
video (in iMovie) at about the same speeed as my 1.6GHz Athlon
based PC in Pinnacle Studio... Hardly a scientific comparison I
know! :-)

Alan G.


Author of the Learn to Program website
<a style='text-decoration: underline;' href="http://www.freenetpages.co.uk/hp/alan.gauld" target="_blank">http://www.freenetpages.co.uk/hp/alan.gauld</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

On Sat, 07 Aug 2004 18:52:38 GMT, Alan Gauld
<alan.gauld RemoveThis @btinternet.com> wrote:

 >On Sat, 07 Aug 2004 11:28:57 +0200, Lothar Scholz
 ><dummy RemoveThis @scriptolutions.com> wrote:
 >
  >> This could be a problem. Apple's computers in the low end sector
  >> (eMac/iMac) are very very slow for todays technology. So this might be
  >> a problem for me. But on the other hand i think in terms of two or
  >> three years for my port. And then at least a 1.25 GHz may be usual.
 >
 >The latest eMac/iMac are both over 1GHz now. And of course the
 >Mac chips are effectively equivalent to a PC chip of about twice
 >the speed(*)(some would say more!). If you really need more grunt
 >than that then it must be a very heavy program indeed!
 >

This is only an urban legend from apple lovers. When i use the "gcc"
to compile c files the speed of a 1 GHz eMac is comparable to the
speed of a 1 GHz PIV:

<a style='text-decoration: underline;' href="http://www.heise.de/ct/english/02/05/182/" target="_blank">http://www.heise.de/ct/english/02/05/182/</a>

(If you keep this in mind you see how overpriced the apple computers
are at the moment - you can get a more then two times faster system
for less money).

And feeling has nothing to do with speed, because normally you mean
responsiveness. BeOS gave the users a very good responsive feeling but
the system was so slow on almost everything.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

On Sat, 07 Aug 2004 21:29:26 +0200, Lothar Scholz
<dummy RemoveThis @scriptolutions.com> wrote:
  > >The latest eMac/iMac are both over 1GHz now. And of course the
  > >Mac chips are effectively equivalent to a PC chip of about twice
  > >the speed(*)(some would say more!). If you really need more grunt
  > >than that then it must be a very heavy program indeed!
 > This is only an urban legend from apple lovers. When i use the "gcc"
 > to compile c files the speed of a 1 GHz eMac is comparable to the
 > speed of a 1 GHz PIV:

It will of course depend on the task at hand, I get the same
effect from my Sun Sparcstation at work. Most of the time the
Sparc completes a job in about the third of the time an
equivalent Pentium PC takes, but for compiling the PC will be
faster because its very CPU intensive and the Pentium is well
architected for that. (Actually the P4 seems to be well
architected for several tasks including my video example)

But for many everyday tasks the macs perform significantly
faster than the simple CPU comparisons indicate - and PC Magazine
benchmarks back that up where they have done side by side tests -
for example using MS Office or Adobe apps.

Personally I can only go by my own experience which is of
comparing a 600M iBook to a 1600M Athlon. The time to render
a 45 minute video on both machines is about 2 hours. Now
I'm using diffderemnt apps and of course rendering video
does require a lot of RAM and Disk access
(Both have 256M RAM FWIW)

<font color=purple> > <a style='text-decoration: underline;' href="http://www.heise.de/ct/english/02/05/182/</font" target="_blank">http://www.heise.de/ct/english/02/05/182/</font</a>>

An interesting page. Thanks for the link. In the tests they focus
on pure CPU/RAM type tasks, which is fair enough thats what Spec
marks measure! But the real world performance is better suited to
an application based test suite. OTOH for developers the Spec
mark results are very significant since they will typically
reflect the performamce a developer will see using compilers etc.

 > And feeling has nothing to do with speed, because normally you mean
 > responsiveness. BeOS gave the users a very good responsive feeling but
 > the system was so slow on almost everything.

BeOS didn't work at any level for me, not even responsiveness!
But real world performamce is the main thing I'm interested in.
FWIW My IBM mainframe runs at a lowly 250MHz but still beats the
pants of all my NT and Sparc boxes for shovelling data around.
But don't try compiling code on it! :-)

Alan G
Author of the Learn to Program website
<a style='text-decoration: underline;' href="http://www.freenetpages.co.uk/hp/alan.gauld" target="_blank">http://www.freenetpages.co.uk/hp/alan.gauld</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

Lothar Scholz wrote:
  >> the speed(*)(some would say more!). If you really need more grunt
  >> than that then it must be a very heavy program indeed!
  >>
 >
 > This is only an urban legend from apple lovers. When i use the "gcc"
 > to compile c files the speed of a 1 GHz eMac is comparable to the
 > speed of a 1 GHz PIV:
 >
<font color=purple> > <a style='text-decoration: underline;' href="http://www.heise.de/ct/english/02/05/182/</font" target="_blank">http://www.heise.de/ct/english/02/05/182/</font</a>>

as if gcc was the only thing computers were good for. gcc is also not
known for being fast or efficient, since wide platform portability is
considered a higher priority, so performance varies wildly from one
platform to another.

 > (If you keep this in mind you see how overpriced the apple computers
 > are at the moment - you can get a more then two times faster system
 > for less money).

yeah, and the best car is the one with the biggest, fastest engine
right? who cares if it even has seats, just so long as it goes faster
than any other cars. what a boringly predictable and narrow view.

i've got a 17-inch aluminum powerbook. it's the most beautiful piece of
consumer machinery i've ever seen. it's unbelievably captivating. it
Just Works in so many ways, it does all kinds of things that were
difficult, awkward or impossible with the last portable i had, a boring
wintel job. almost everyone who's ever seen my powerbook has fallen in
love with it, especially non-computer people. all those same people
looked right past my previous portable as if it wasn't there, it was
just a lump of plastic. my powerbook HAS A SOUL.

 > And feeling has nothing to do with speed, because normally you mean
 > responsiveness. BeOS gave the users a very good responsive feeling but
 > the system was so slow on almost everything.

i was (and still am) so much into beos that i once worked for be, so i
feel qualified to say that, here, you just plain old have no idea what
the hell you're talking about.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ? 

In article <jpaah0ldbnvn4je7mthmdnqiocnbpvpfev RemoveThis @4ax.com>,
Lothar Scholz <dummy RemoveThis @scriptolutions.com> wrote:

 > On Sat, 07 Aug 2004 18:52:38 GMT, Alan Gauld
 > <alan.gauld RemoveThis @btinternet.com> wrote:
 >
  > >On Sat, 07 Aug 2004 11:28:57 +0200, Lothar Scholz
  > ><dummy RemoveThis @scriptolutions.com> wrote:
  > >
   > >> This could be a problem. Apple's computers in the low end sector
   > >> (eMac/iMac) are very very slow for todays technology. So this might be
   > >> a problem for me. But on the other hand i think in terms of two or
   > >> three years for my port. And then at least a 1.25 GHz may be usual.
  > >
  > >The latest eMac/iMac are both over 1GHz now. And of course the
  > >Mac chips are effectively equivalent to a PC chip of about twice
  > >the speed(*)(some would say more!). If you really need more grunt
  > >than that then it must be a very heavy program indeed!
  > >
 >
 > This is only an urban legend from apple lovers.

No. It's more like recognition of the fact that some machines are better
suite to some tasks than others. The first Mac in my company was a
600MHz G3 iMac, bought for automated image conversions. It was brought
in because it beat the pants off any solution we could build on the
P3/1GHz that was pretty much the high-end x86 at the time.


 > (If you keep this in mind you see how overpriced the apple computers
 > are at the moment - you can get a more then two times faster system
 > for less money).

Depending on the task your performing, and assuming speed of
non-interactive processes is your primary goal.


 > And feeling has nothing to do with speed, because normally you mean
 > responsiveness. BeOS gave the users a very good responsive feeling but
 > the system was so slow on almost everything.

Disagree. BeOS was always quite perky for me, especially on my BeBox but
I also used it on a 604e PowerMac and a Pentium II.

G

--
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses. - Jeremy Nixon<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Cocoa or Carbon ?