On Apr 8, 2009, at 5:51 PM, Gerriet M. Denkmann wrote:
On 9 Apr 2009, at 02:03, "Sean McBride" <s...@rogue-research.com>
wrote:
On 4/7/09 9:04 PM, Jo Phils said:
As for not using Carbon I suppose there's no reason I can't use
it. I
was just thinking with Finder going away from Carbon and since
I'm just
learning Cocoa I was trying to avoid it if I could. But if it's the
best way I can use it...
Carbon is an overloaded term, it means many things all at once.
Yes. This has confused me a lot.
I would propose to use only the term "Carbon application" as
defined in:
"Carbon application" ::= app whose main.c file is very big (more
than 5000 characters) and contains InstallApplicationEventHandler().
as opposed to:
"Cocoa application" ::= app with a very small main.m (less than 100
characters) which contains NSApplicationMain().
And NOT to use the term "Carbon" (other than in "Carbon
application"), but to use the term "C-function" instead.
Like:
"To get the file size one can use some methods in NSFileManager,
or, if one needs more detailed information (e.g. physical size,
sizes of resource fork), one can use the C-functions documented in
the File Manager Reference (defined in Files.h), which are part of
the CoreServices.framework."
I don't know about an "official definition," but my definition of a
Carbon application is one that uses either a Carbon nib or resource
fork-based user interface components, i.e., legacy menu manager,
control manager (or HIViews), window manager, etc., even if it uses
Cocoa to perform some tasks.
My definition of a "Cocoa application" is one that uses a Cocoa nib
and/or user interface components based off of NSView, NSWindow, etc.,
even if it calls the C-based File Manager, Core Foundation, Quartz,
etc., to perform some particular task.
To give an example of my confusion about the term "Carbon": The
aforementioned "File Manager Reference" contains this sentence: "In
Carbon, this name must be a leaf name; the name cannot contain a
semicolon."
That is unrelated to any Carbon/Cocoa definition. File Manager path
names separate path components with colons (:) instead of slashes (/).
Or: "the Carbon File Manager does not return the number of files in
this field"
I guess this would depend on which API call and which parameter this
refers to.
A somehow unrelated question:
What would be a rational reason to create a new "Carbon
application" today?
You're more comfortable working in C or C++ and your intention is
that the application you create will only be used in a 32-bit
environment.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
