Coming from the Linux/Windows World
- Thread starter gamehack
- Start date
Viro
Registered
Forget C#. It isn't really usable on OS X since Mono is way way way behind on OS X compared to Linux. Stick with C++ and your options are Qt, wxWidgets or Carbon. I'd personally recommend Qt because it's portable, and applications look kinda native. wxWidgets applications look even better, but the toolkit itself isn't as well documented as Qt.
Or you could learn Objective-C. It's quite a nice language, once you get used to it.
Or you could learn Objective-C. It's quite a nice language, once you get used to it.
ElDiabloConCaca
U.S.D.A. Prime
C++ is fine for Mac OS X development.
You'll need a copy of XCode 1.5, which includes everything you need to write, compile, and create an interface for any project you want. It's available for free either by downloading it from Apple's Developer website, or from the CD that comes with retail versions of Mac OS X.
You'll need a copy of XCode 1.5, which includes everything you need to write, compile, and create an interface for any project you want. It's available for free either by downloading it from Apple's Developer website, or from the CD that comes with retail versions of Mac OS X.
Straight C++ for Mac development means you will be doing "legacy" Carbon coding. Personally, this isn't what you want to do if you'll be investing time creating software for Mac OS X.
Objective-C is what you do want to learn. Objective-C is a superset of C, however Xcode allows you to develop in Objective-C++, so all that C++ code you have is usable in your Cocoa program.
I'd suggest you do learn Objective-C for the UI interaction, but for your logic stick with C++ if that's what you know best. Mac OS 10.3 makes UI easy with bindings which requires no code at all. Just some connections in Interface Builder and you have a program!
Objective-C is what you do want to learn. Objective-C is a superset of C, however Xcode allows you to develop in Objective-C++, so all that C++ code you have is usable in your Cocoa program.
I'd suggest you do learn Objective-C for the UI interaction, but for your logic stick with C++ if that's what you know best. Mac OS 10.3 makes UI easy with bindings which requires no code at all. Just some connections in Interface Builder and you have a program!
Thanks a lot for the replies. I've some other questions though So can I use C++ with Carbon or Cocoa? From what I understand Cocoa is like an abstraction on top of Carbon, which itself is written in C(Obj-C?). Does Apple provide C++ bindings for either Carbon or Cocoa?
Thanks a lot
So can I use C++ with Carbon or Cocoa? From what I understand Cocoa is like an abstraction on top of Carbon, which itself is written in C(Obj-C?). Does Apple provide C++ bindings for either Carbon or Cocoa?Thanks a lot
Viro
Registered
No, Cocoa and Carbon are separate. Carbon is for legacy apps, and is a C based API very similar to Win32. In fact, there is nearly a one to one mapping between function calls as Win32 and Carbon are so similar. That's been my experience anyway, for my little exploits into carbon.
Apple doesn't provide C++ bindings for either Carbon or Cocoa. There are C++ bindings for Carbon. Qt and wxWidgets use Carbon to render all widgets, so if you use these toolkits, your resulting application will behave just like a carbon app. For Cocoa, at the moment only wxWidgets has a Cocoa backend, and it looks quite nice!
The benefit of both wxWidgets and Qt is that your programs are going to be highly portable. I personally suggest you try one of these.
Apple doesn't provide C++ bindings for either Carbon or Cocoa. There are C++ bindings for Carbon. Qt and wxWidgets use Carbon to render all widgets, so if you use these toolkits, your resulting application will behave just like a carbon app. For Cocoa, at the moment only wxWidgets has a Cocoa backend, and it looks quite nice!
The benefit of both wxWidgets and Qt is that your programs are going to be highly portable. I personally suggest you try one of these.
Viro
Registered
Yes. But it isn't very visible .
The only example I can think off that is very visible is the way tabs are rendered in Panther. Using Carbon, your tabs will look like tabs, while using Cocoa, your tabs will look like 'lozenges'.
But the differences are minor. MS Office is using Carbon and it looks alright.
.The only example I can think off that is very visible is the way tabs are rendered in Panther. Using Carbon, your tabs will look like tabs, while using Cocoa, your tabs will look like 'lozenges'.
But the differences are minor. MS Office is using Carbon and it looks alright.
There's one very useful visual difference between Carbon and Cocoa, and you can sometimes use it to pick out a Carbon app: window resizing. Carbon has a window style flag that allows the window to be resized without showing the contents of the window. What I mean is, when you hold down that lower right corner and start dragging, you get a dotted line marquee kinda like the Photoshop selection marquee, while you're resizing the window. Let go of the mouse button and the window resizes. Resizing the window while showing its contents is call "live resize" and to my knowledge, all Cocoa windows are set to live resize.
EDIT: Oops forgot to mention why it's useful! Back in 10.1 and 10.2, I still felt the UI performance sucked. Window resizing was a huge pain for my iMac and iBook. I was more thrilled to be using Carbon based apps, and went as far as trying to make a Finder replacement in Carbon. Carbon apps just felt a little more lite weight to me I guess.
And just for the sake of discussion, if you've done Win32, the event model of Carbon will make you fall out of your chair. But when you get back up, eventually you'll fall in love with it. I did
And for the record Cocoa is not superior over Carbon. Says Apple, not just me. They both are the same, granted certain nifty integration system-services are only available to Cocoa. If you don't need those services then Carbon and Cocoa are basically equals. As someone with a Windows/Linux background I found Carbon less obnoxious to my programmer instincts. Cocoa just doesn't fit me well.
EDIT: Oops forgot to mention why it's useful! Back in 10.1 and 10.2, I still felt the UI performance sucked. Window resizing was a huge pain for my iMac and iBook. I was more thrilled to be using Carbon based apps, and went as far as trying to make a Finder replacement in Carbon. Carbon apps just felt a little more lite weight to me I guess.
And just for the sake of discussion, if you've done Win32, the event model of Carbon will make you fall out of your chair. But when you get back up, eventually you'll fall in love with it. I did
And for the record Cocoa is not superior over Carbon. Says Apple, not just me. They both are the same, granted certain nifty integration system-services are only available to Cocoa. If you don't need those services then Carbon and Cocoa are basically equals. As someone with a Windows/Linux background I found Carbon less obnoxious to my programmer instincts. Cocoa just doesn't fit me well.
Cocoa can produce real applications much much faster then Carbon. Carbon = tons of C/C++ code, slaving over it all day and night just to do stupid stuff like get a window to show
But Cocoa does all the stupid stuff for you. With bindings, you have to write very little code to get things done.
But Cocoa does all the stupid stuff for you. With bindings, you have to write very little code to get things done.
kainjow: You do know that Carbon can load a window from a NIB resource right? Afterwards it's pretty trivial to get into the event handler for each of the controls.
For me at least, it takes longer for me to wrap my mind around Cocoa's message/signal mechanism and syntax.
Heck, once you have the basics down just copy/paste. I can type faster than sitting there playing connect-the-dots in IB. Even after it spits out the template code I'd have to go back in and tweak it some more.
Oh, have you ever setup a GUI in IB, save out the source files, but then later have to go back and add one more thing? Like say you needed one more button, so you add it after the fact, and setup all those bindings etc. Now you go to save out the source files again... but wait! Uh oh! You've already started coding the implementation. Writing out the new interface template would wipe out existing code.
Aha! But there's this very slick file diff program, you say. Yeah, props to Apple, that's by far the best and most fun to use code diff program I've ever used. But then you're sitting there going through your source file hand picking chunks of code to merge the 2 files together. Most of the time it's simple enough that we can say "the heck with it" and just save the new version elsewhere and copy/paste the code differences.
Well the above workflow, in my opinion, sucks. I rather just write my GUI as I go along. As much as people argue the WYSIWYG HTML editors like Dreamweaver making a mess, the same kinda holds true with WYSIWYG app builders.
For me at least, it takes longer for me to wrap my mind around Cocoa's message/signal mechanism and syntax.
Heck, once you have the basics down just copy/paste. I can type faster than sitting there playing connect-the-dots in IB. Even after it spits out the template code I'd have to go back in and tweak it some more.
Oh, have you ever setup a GUI in IB, save out the source files, but then later have to go back and add one more thing? Like say you needed one more button, so you add it after the fact, and setup all those bindings etc. Now you go to save out the source files again... but wait! Uh oh! You've already started coding the implementation. Writing out the new interface template would wipe out existing code.
Aha! But there's this very slick file diff program, you say. Yeah, props to Apple, that's by far the best and most fun to use code diff program I've ever used. But then you're sitting there going through your source file hand picking chunks of code to merge the 2 files together. Most of the time it's simple enough that we can say "the heck with it" and just save the new version elsewhere and copy/paste the code differences.
Well the above workflow, in my opinion, sucks. I rather just write my GUI as I go along. As much as people argue the WYSIWYG HTML editors like Dreamweaver making a mess, the same kinda holds true with WYSIWYG app builders.
give me a break.. please dont even try to compare Qt to Cocoa.. Cocoa is far superior.. as of Tiger you can create a full fledge Word processor without writing any code. pfft. Cocoa's simplicity is just outstanding. It is by for the most productive GUI application API I've come across.
PS: I'm not primarily a Cocoa programmer, but more of a Java programmer. I've looked at C++ windowing tookits,, they are all far too horrible, except maybe for Qt. In the Java world, i enjoy the highly productive standard API that comes along with the implementation, its more productive than any other "standard" library i've seen to date. But it's SWING framework is nothinging in comparison to Cocoa.
Simply put: Cocoa pwns.
PS: I'm not primarily a Cocoa programmer, but more of a Java programmer. I've looked at C++ windowing tookits,, they are all far too horrible, except maybe for Qt. In the Java world, i enjoy the highly productive standard API that comes along with the implementation, its more productive than any other "standard" library i've seen to date. But it's SWING framework is nothinging in comparison to Cocoa.
Simply put: Cocoa pwns.
Lycander... you do realize the Finder is Carbon. The main third-party Finder replacement (PathFinder) is Cocoa.
And yes, I did get a "job" with the attitude of Cocoa is better then Carbon. Cocoa's main strength is that you can create professional apps much quicker then most other API's available on any other platform.
How many new apps for Mac OS X are created in Carbon and are successful? Not much besides the apps from the OS 9 days. Most, if not all, new development is done in Cocoa. Carbon is fine if it's what you know.
P.S. Please don't get upset about Cocoa vs Carbon arguments. Choose what you feel is the best for the job and for you. I chose Cocoa, you chose Carbon. Nothing wrong with that.
And yes, I did get a "job" with the attitude of Cocoa is better then Carbon. Cocoa's main strength is that you can create professional apps much quicker then most other API's available on any other platform.
How many new apps for Mac OS X are created in Carbon and are successful? Not much besides the apps from the OS 9 days. Most, if not all, new development is done in Cocoa. Carbon is fine if it's what you know.
P.S. Please don't get upset about Cocoa vs Carbon arguments. Choose what you feel is the best for the job and for you. I chose Cocoa, you chose Carbon. Nothing wrong with that.
I'm not getting upset over Carbon vs. Cocoa. Not at all. Actually I'm API agnostic. I just don't think Cocoa is be all end all.
And I'm not trying to say you can't get a job doing Cocoa programming. That was vague on my part, I apologize. What I'm trying to say (should have said to begin with) is don't bet on one single API.
You asked how many new apps for MacOSX created in Carbon are successful? Alias Maya, Macromedia Dreamweaver, and basically any app that is cross platform. That's the key here. Cocoa (more importantly Objective-C and its runtime) doesn't exist in other OSes (I'm not counting NeXT or OpenStep) so to port a commercial app to OSX will have to be done with C/C++ and Carbon. Ta da! That's why we need and have cross platform GUI toolkits like Qt.
And I'm not trying to say you can't get a job doing Cocoa programming. That was vague on my part, I apologize. What I'm trying to say (should have said to begin with) is don't bet on one single API.
You asked how many new apps for MacOSX created in Carbon are successful? Alias Maya, Macromedia Dreamweaver, and basically any app that is cross platform. That's the key here. Cocoa (more importantly Objective-C and its runtime) doesn't exist in other OSes (I'm not counting NeXT or OpenStep) so to port a commercial app to OSX will have to be done with C/C++ and Carbon. Ta da! That's why we need and have cross platform GUI toolkits like Qt.