[dfbennett]

I was fiddling around in OS 9.1 today and I decided to try and run some Carbon apps that i usually run under X in 9.1. I tried the new AOL instant messenger beta and it ran flawlessly in 9.1 just like X. It amazes me that one program written in one language can run flawlessly on two very different operating systems. Without carbon, I think OS X would have been dead in the water(not that I'm bad mouthing Cocoa). Now if they could only make it so that all carbon apps use the scroll wheel I'd be very happy

[pinlo]

Originally posted by dfbennett:
<STRONG>I was fiddling around in OS 9.1 today and I decided to try and run some Carbon apps that i usually run under X in 9.1. I tried the new AOL instant messenger beta and it ran flawlessly in 9.1 just like X. It amazes me that one program written in one language can run flawlessly on two very different operating systems. Without carbon, I think OS X would have been dead in the water(not that I'm bad mouthing Cocoa). Now if they could only make it so that all carbon apps use the scroll wheel I'd be very happy </STRONG>

I agree with you. Also, making services available to Carbon apps (something Apple has said they will do).

[pinlo]

duplicate

[ 07-13-2001: Message edited by: pinlo ]

[applenut1]

Originally posted by dfbennett:
<STRONG>I was fiddling around in OS 9.1 today and I decided to try and run some Carbon apps that i usually run under X in 9.1. I tried the new AOL instant messenger beta and it ran flawlessly in 9.1 just like X. It amazes me that one program written in one language can run flawlessly on two very different operating systems. Without carbon, I think OS X would have been dead in the water(not that I'm bad mouthing Cocoa). Now if they could only make it so that all carbon apps use the scroll wheel I'd be very happy </STRONG>

wow. you are very easily amused.

carbon still sucks though... or better.. carbon apps still suck

Originally posted by applenut1:
<STRONG>

wow. you are very easily amused.

carbon still sucks though... or better.. carbon apps still suck</STRONG>

Some things about Carbon suck but I wouldn't say it sucks as a whole, or that all apps written with it suck. It's actually very rare that I use a Cocoa app at all, I actually end up using Classic apps more often.

The lack of system-wide scroll wheel support for Carbon scroll bars sucks, and I suppose there will be an interesting Service publshed someday (I can't think of one offhand (maybe the brain dead spell checker), but you never know). I could do without ever seeing a Drawer slide out from the side of a window to provide access to some element of the UI that could be better done another way (at least in every example that I've ever seen).

Does the mouse scroll wheel work in the finder column view?

[moreno]

the amazing of carbon is Internet Explorer...
i can't believe that apple make the internet explorer the default webbroswer on a multitasking OS when, it stops all operations when you select a menu...

[krove]

Ugh, as of today, carbon most definitely suck, even if the developer has tweaked the code to utilize calls that are the most efficient.

Reasoning: Open your Process Viewer application and note the CPU usage by the "LaunchCFMApp" lines. Those are the carbon apps. Even when doing nothing, they seem to hog a fair amount of CPU (i.e. AIM, iTunes even when not playing, etc). When several are open, it gets to the point where there isn't much CPU left to go around, when actually, nothing is visibly being done for the user.

The more Cocoa apps available, the better...

Originally posted by krove:
<STRONG>Open your Process Viewer application and note the CPU usage by the "LaunchCFMApp" lines. Those are the carbon apps. Even when doing nothing, they seem to hog a fair amount of CPU (i.e. AIM, iTunes even when not playing, etc). When several are open, it gets to the point where there isn't much CPU left to go around, when actually, nothing is visibly being done for the user.

The more Cocoa apps available, the better...</STRONG>

ProcessViewer is braindead, use top from the terminal as it'll show you the actual program name associated with the different processes. On my 400 MHz machine (by no means a powerhouse, mind) I don't get any process taking up more than 4%, and usually closer to 0-2%, when it's sitting in the background. Well, Classic but that has Entourage going and I'll deal with the 12% or whatever it takes so I don't have to deal with Apple's crappy mail program. Do this: "top -u -s5 15" which will show you the top 15 processes sorted by CPU time consumed, with a 5 second sample size.

Not that I have anything against Cocoa, there just aren't any apps written in it that I use often. Terminal, the Dock, that Audio CD dockling, System Prefs, you get the idea. OmniWeb is close, but it tends to bog down on my system with more than one window open, and the last time I used it, it hated the ESPN site redesign.

Originally posted by applenut1:
<STRONG>

wow. you are very easily amused.

carbon still sucks though... or better.. carbon apps still suck</STRONG>

Originally posted by applenut1:
<STRONG>

wow. you are very easily amused.

carbon still sucks though... or better.. carbon apps still suck</STRONG>

This is such a ridiculously uninformed opinion. I'm really quite sick of idiots who haven't the first clue about programming making sweeping statements about Cocoa or Carbon.

Cocoa is a nice OO API, if you don't mind Objective C (which I don't -- I actually like the Smalltalk-ish syntax). It's patently absurd to say that Cocoa apps are "better" or "faster" than than Carbon apps, or the other way around, for that matter.

Cocoa or Carbon is a choice of programming APIs, and nothing more. Applenut, get a clue.

Originally posted by krove:
<STRONG>Ugh, as of today, carbon most definitely suck, even if the developer has tweaked the code to utilize calls that are the most efficient.

Reasoning: Open your Process Viewer application and note the CPU usage by the "LaunchCFMApp" lines. Those are the carbon apps. Even when doing nothing, they seem to hog a fair amount of CPU (i.e. AIM, iTunes even when not playing, etc). When several are open, it gets to the point where there isn't much CPU left to go around, when actually, nothing is visibly being done for the user.

The more Cocoa apps available, the better...</STRONG>

Once again, another uninformed opinion. Here are the mistakes you made:

1) It is possible to write a poorly written Carbon app, just as it is possible to write a poorly written Cocoa app. Many quick ports use the old WaitNextEvent() event dispatch mechanism instead of Carbon Events, and thus they use up more CPU when idling than properly written Carbon apps that use Carbon Events. Don't blame Carbon for people's quick and dirty ports.

2) My carbon app takes up 0.0-0.3% CPU when it is idling in the background; tell me again how Carbon sucks? Have you ever written a program in your life?

3) Do you even realize that Carbon apps do not have to be CFM apps? You can't spot a Carbon app by simply looking for LaunchCFMApp -- it is entirely possible to write a macho carbon app, and in fact, a number of apps that Apple ships are macho carbon apps.

In short, stop spouting off about things you have no understanding about. I realize everyone wants a scapegoat for OS X being slow, but the real answer is that Apple needs to fix OS X. Clamouring for Cocoa apps is just stupid (or has no one notice that OmniWeb, a Cocoa app through and through, is the slowest web browser on the planet?)

[krove]

Yes, yes and yes...no where did I assume that all Carbon apps were CFM apps, but I did say that all CFM-labeled apps are most definitely carbon ones.

Yes I've programmed applications before. With carbon, in my opinion, it is much easier to write a bogged down, inefficient app (damn you lazy developers). I'm not saying it applies to all carbon apps, just those that I mentioned. Don't get all bent out of shape and don't assume that I'm some sort of idiot because you read too much into my post...

Lastly, yes, I know how to use top ... it just depends what I'm in the mood for, that's all. Tonight it was Process Viewer.

[michaelb]

The big problem is with all these Carbon vs Cocoa discussions is that there is actually no such thing as pure Carbon or pure Cocoa.

Cocoa apps can call the Carbon API. Carbon apps can call the Cocoa framework. Furthermore, some of the Cocoa framework actually wraps the Carbon API for Cocoa programmers.

Cocoa apps often have to call Carbon because much of the traditional Mac toolbox is not yet wrapped into Cocoa - for example, almost anything related to QuickTime has to go through Carbon.

For a Carbon app, even if the app is compiled completely against CarbonLib, there are many degrees of pureness - some apps use CarbonEvents, whilst many still use a traditional WaitNextEvent() loop. As mentioned in a post above, some Carbon apps are combiled into Mach-O binaries ("native" for OS X) while others stay Code Fragment Manager (for compatibility with both 9 and X).

The simple conclusion is that it has far more to do with how an app's code interacts with Mac OS X in a global sense than the API it is predominantly interacting with.

At the end of the day (or the compile), code is code.

[krove]

Ok...ok...so carbon isn't that bad, one can agree that code is code, but also that some code is bad code (cocoa or carbon)....

Time for this thread to die...