Re: Are screensavers for OS X made in Cocoa or Java?
Re: Are screensavers for OS X made in Cocoa or Java?
- Subject: Re: Are screensavers for OS X made in Cocoa or Java?
- From: Hex Star <email@hidden>
- Date: Fri, 28 Oct 2005 15:39:23 -0700
Thank you all for your replies, they are very helpful and I will be
sure to keep them in mind :-)
On 10/28/05, James Spencer <email@hidden> wrote:
>
> On Oct 26, 2005, at 10:51 PM, Hex Star wrote:
>
> > alright I just wanted some clarification because I saw on one site it
> > mentioned that the Cocoa library could be used via either Objective C
> > or Java??? So I guess this means the screensavers are done in
> > Objective C which would also eliminate Carbon? Thanks, and yes I
> > embarrasingly am a newb when it comes to the mac programming sector so
> > please be patient with me :-)
> >
>
> You are mixing apples and oranges.
>
> Objective C and Java are programming languages while Cocoa and Carbon
> are APIs and frameworks for producing Macintosh programs. As you are
> apparently familiar with Java, Cocoa and Carbon are essentially Swing
> in native format. Both Carbon and Cocoa can be used from several
> different languages although Carbon is usually accessed using C (it
> is a C procedural API) and Cocoa is accessed using Objective C or
> Java (Cocoa being an object based API, it needs an OOP language for
> access). (Other object oriented languages have been can be used via
> bridges.) While you can program most Cocoa programs using Java, is
> not all of the Cocoa API supports Java and as one of the other
> writers indicated, I'm not sure whether the Cocoa screensaver API is
> one of those that is Objective C only or not.
>
> Cocoa and Carbon are not exclusive: you can make calls to the Carbon
> API from Cocoa programs and call the Cocoa API from Carbon programs.
> Your statement that "So I guess this means the screensavers are done
> in Objective C which would also eliminate Carbon" is wrong because
> Objective C is a superset of C. ANYTHING you can do in C, including
> calling procedural APIs such as Carbon, is supported in Objective C.
> Obviously the opposite is not true; a plain C compiler can't do
> objects but the gcc compiler does both so if you are going to access
> both Cocoa and Carbon from the same program, you just compile it as
> an Objective C program.
>
> In fact, gcc can do do Objective C++ so that from one program, you
> can access Cocoa using Objective C object syntax, Carbon using
> standard procedural function calls, and access some C++ class using C+
> + object syntax. This means you could have in one function or method
> (what Java calls a member function) the following code:
>
> ...
> // create a Cocoa object and call a method:
>
> NSSomeObject *objectReference = [[NSSomeObject alloc]init];
> [objectReference someMethod:parameter];
>
> // Now, in the same function, call a Carbon function
> int returnValue = SomeCarbonFunction(parameter);
>
> // finish up with some C++ code, first using a stack based
> // object, something not permitted in Objective C
>
> SomeClass myCplusplusObject;
> myCplusplusObject.memberFunction(parameter);
>
> // or do the same with dynamic allocation
> SomeClass * myCplusplusObjectPtr;
> myCplusplusObjectPtr = new SomeClass;
> myCplusplusObjectPtr->memberFunction(parameter);
> ...
>
> This will all work simply by using the Objective C++ compiler
> (usually invoked automatically by giving the file name for this code
> a "mm" file extension).
>
> Obviously, if you think about it, there are limitations on mixing the
> APIs up too much. For example both Cocoa and Carbon have their own
> run loops and those will conflict if both exist so you want to use
> one or the other (automatically taken care of for you using the
> default stationary projects in Xcode) but the point is that if there
> is some facility in one that is not available in the other, can just
> go ahead and call the other so long as you include the appropriate
> headers in your code and link in the appropriate frameworks in your
> project.
>
> James P. Spencer
> Rochester, MN
>
> email@hidden
>
> "Badges?? We don't need no stinkin badges!"
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden