OS X Aqua programming WITHOUT Xcode?

[Matadon]

Does anyone have some good pointers to documentation on writing native Cocoa/Aqua apps in Objective-C that DON'T just go through XCode and Interface Builder?

I'd like to get a solid handle on the way the system works, and I'm also working on learning how to write GUI code in a solid, readily-portable manner. That, and I prefer to do all of my coding in vi, thanks. Interface Builder and XCode aren't condusive to any of this.

So, any helpful links?

 

[ksv]

Does anyone have some good pointers to documentation on writing native Cocoa/Aqua apps in Objective-C that DON'T just go through XCode and Interface Builder?

I'd like to get a solid handle on the way the system works, and I'm also working on learning how to write GUI code in a solid, readily-portable manner. That, and I prefer to do all of my coding in vi, thanks. Interface Builder and XCode aren't condusive to any of this.

So, any helpful links?

You have to lay off that *nix conservatism and be more open to other practices if you want to develop Mac OS X GUIs. vi is appropriate for coding cross-platform command line programs, not complex object oriented GUIs. Xcode and Interface Builder is the way to go, even for *nix über-professionals.

Complex applications developed in parallel for multiple platforms often share a C or C++ Standard Library core which is interfaced to the various platform-specific layers. Cocoa is one of those. The Mac OS X version of a cross-platform application often uses a mix of C++ and Objective-C, called Objective-C++, to achieve that practically.

"Cocoa Programming for Mac OS X", "Practical C++ Programming" and "Core Mac OS X and UNIX Programming" are good book titles on these subjects.

 

[lurk]

Just another note on the topic of IB. One of the big wins in aqua is that the UI is basically just an OO object graph. That has all sorts of good features like allowing you to create the GUI in an editor and serialize it to disk (that is what IB does) then the GUI is just deserialized at runtime and your are golden.

This is also trivial to do by hand in vi, just instantiate the objects and hook 'em up. Tedious and error prone as all get out, but easy. I would suggest just looking at the docs for each component and how to create it and set the 50 fields to sensible defaults.

/ masochism -- its what's fer dinner!

 

[Viro]

From my limited experience with Cocoa programming, it is inherently tied to Xcode and IB. That's not necessarily a bad thing, but like the OP said, it can be quite unconducive to learning as you have to learn not only a new language and API, but a whole new IDE as well.

 

[HateEternal]

That's not necessarily a bad thing, but like the OP said, it can be quite unconducive to learning as you have to learn not only a new language and API, but a whole new IDE as well.

I think the time saved not coding from scratch in VI offsets the amount of time used to learn the IDE.

I understand where he is coming from is well, generally I hate stuff that generates code for you or has any sort of 'magic' involved, but this is one of those instances where I embrace it :-D

 

[lurk]

The important thing in this case it that it is not generating code for you a la Visual Studio and the like. You are creating actual objects which you then manipulate. These are then "freeze dried" into a nib file. No code is generated.

This can really be hard for people comming from impovrished programming systems to understand. If you have ever used Smalltalk for example it is a beutiful and simple thing.

// Sorry for the typos and all. I am posting form my wife's office in explorer, shudder.

 

[Viro]

The important thing in this case it that it is not generating code for you a la Visual Studio and the like. You are creating actual objects which you then manipulate. These are then "freeze dried" into a nib file. No code is generated.

This can really be hard for people comming from impovrished programming systems to understand. If you have ever used Smalltalk for example it is a beutiful and simple thing.

Agreed. I come from a C++ and Java background, and I find Objective-C and Cocoa immensely difficult, mainly because I don't understand what's going on behind the scenes. What's actually happening when I instantiate an object in IB? Where is the code? I haven't found a guide that deals with such issues, as most tutorials/articles/ and book I've read just tell you what to do and assume you aren't curious as to what's going on behind the scenes.

 

[lurk]

Agreed. I come from a C++ and Java background, and I find Objective-C and Cocoa immensely difficult, mainly because I don't understand what's going on behind the scenes. What's actually happening when I instantiate an object in IB?

Well this is really kind of cool. In IB when you make a window object and add say a button you are actually manipulating instances of NSWindow and NSButton. You are working with actual real objects. When you save a nib file the root object, say the window, is serialized to a data object. In this process the whole object graph is included. This is very similar to object serialization in Java. Later at runtime this freeze-dried object graph is decoded from the data stored in the nib file.

This is different than C++ style gui builders because in those cases you never actually interact with real gui objects. Rather, they are pretend components that are then used to drive the generation of code to generate the real components.

Where is the code?

There is no code. You are manipulating the actual objects themselves which are then serialized and de-serialized from a data object.

I haven't found a guide that deals with such issues, as most tutorials/articles/ and book I've read just tell you what to do and assume you aren't curious as to what's going on behind the scenes.

Well part of the problem is that you are expecting more is going on than is. You should look at NSCoding to see how things are saved and retrieved from the data file and NSBundle to tell you about how the base object is retrieved from the nib file.

I am more than happy to answer more questions, it really is simple but very different that you might be familiar with. When it clicks you will know.