Comments on: The Cocoa-Carbon Advantage Official blog of Red Sweater Software Tue, 06 Oct 2015 01:25:36 +0000 hourly 1 By: Daniel Jalkut Wed, 27 Sep 2006 17:34:48 +0000 Agree with Eric, especially considering that there are behaviors that are better in Carbon than in Cocoa. So it goes both ways. And if Apple didn’t want to support Carbon, they would have made that a lot clearer than just a few UI glitches. Remember Classic?

By: Eric Albert Wed, 27 Sep 2006 17:30:43 +0000 I’d suggest not ascribing to politics what can more easily be explained by there being more important things to fix.

By: Neo Wed, 27 Sep 2006 04:38:12 +0000 Sadly this demonstrates why one must prefer one part of OS X over the other: Carbon is out of sync from Cocoa (and vice versa).

The icon returned should be exactly the same, but NSWorkspace is apparently doing some voo-doo to get the *most current* preferred icons. ThIs implies that NSWorkspace is designed to go and get a different icon than what is actually defined in the bowels of OS X.

This preferential treatment of Cocoa is what really irks (some) old-school Carbon developers. Apple engineers are intentionally making Carbon appear antiquated or “broken” compared to Cocoa, even though Carbon is technically capable of regurgitating the correct, modern, icon.

Another area where Carbon is deliberately hindered vs. Cocoa is in the “grow thumb” in Carbon windows, which appears as a solid-white background square instead of transparent as in Cocoa-derived windows. Carbon can make the grow thumb appear identical to Cocoa windows, it is simply not the default appearance for no technical reason whatsoever (just political ones, methinks, but what do I know).

By: Nathan Herring Tue, 19 Sep 2006 18:12:03 +0000 Alas, there are two issues with using Cocoa intermixed with Carbon that have a deleterious effect on performance.
(1) Loading of extra libraries at launch (not a terribly big deal)
(2) You cannot unload Cocoa-based bundles as the Objective-C runtime cannot guarantee that all objects lifetimes are terminated.
That said, the post and the comments are spot on.

By: Louis Tue, 12 Sep 2006 12:35:38 +0000 Cocoa is excellent for interfaces, but sadly it lacks a lot of things that can be found in carbon. I prefer cocoa, but I’m not afraid to use carbon where cocoa falls short.

By: Chris Thomas Mon, 11 Sep 2006 03:09:32 +0000 Daniel: I, too, have Carbon icon code in some of my Cocoa apps. I think there is a point being overlooked in the discussion of NSWorkspace vs GetIconRef. IconServices was designed (partly) to minimize memory usage: for each icon on the system, there should be one and only one instance of pixel data/cache in memory, and all applications should render the icon from that same instance data via PlotIconRef.

So, try this:

Call [[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode(‘prof’)]; three times in the same function, logging the result with NSLog(“%@”) after each.

Call GetIconRef and printf(“%08lX”) the resulting iconRef three times.

Notice the difference? (Aside from the much richer description returned by NSLog…)

This is a much bigger problem with file-specific icons retrieved through NSWorkspace, where you might invoke iconForFile: way too often if you aren’t aware of the problem. You can cache the generic icon (still once per app rather than once per system, though). File-specific icons, not so much.

Rosyna: What does Cocoa have to do with Aperture’s slowness, especially in the 1.0? Unless they ported it to Carbon in 1.1, I find it unlikely that you can pin that on Cocoa. But if you can really trace Aperture’s performance issues to indiscriminate use of Cocoa rather than Carbon, I and others would certainly like to see the analysis.

By: frank riffold Sun, 10 Sep 2006 21:42:40 +0000 In some (non-gui) apps the Carbon framework can come in handy for specific tasks ( cf. How to detect string encoding? on ).

By: Noodlings » System Icon Viewer Sun, 10 Sep 2006 16:44:52 +0000 […] When I saw this post, I mentioned to Daniel Jalkut that I had done the same thing that he did (which was to create an NSImage category to access Carbon’s Icon Manager’s icons). After his obligatory insistence that I start a blog, I sent him a little program I had thrown together to preview the icons. […]

By: Rosyna Sun, 10 Sep 2006 08:17:16 +0000 Scott Stevenson, and notice how slow Aperture is, especially the 1.0?

The NSWorkspace method is getting the icon for the file that has a create code of ‘????’ (ie, any) and the file type you give it. Your GetIconRef is getting the icons with a creator of kSystemIconsCreator (‘macs’), which is a very, very specific domain/application. If you passed ‘????’ to the GetIconRef() function, you’d get the same result. Although you really should use GetIconRefFromTypeInfo(), which is *exactly* what NSWorkspace’s iconForFileType: is doing. However, try drawing the image returned from iconForFileType: in any size than 32×32.

By: Helge Sun, 10 Sep 2006 07:22:26 +0000 To those people who don’t believe Carbon applications can look and feel like Cocoa applications: Check out the Nano framework, which is “pure” Carbon:

Take a look at the example applications. I’m sure almost every Mac user would assume they were Cocoa.