Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

bahlquist

macrumors member
Original poster
Oct 6, 2010
41
0
I want to understand what code Xcode produces so that, if I wanted, I could write all the files for my program in a text editor and compile them from a Unix command line. In my simple example (using Interface Builder), I have a single button: an object of the class NSButton which I call buttonToPress, and some text: an object of the class NSTextField which I call numberToDisplay. Using Interface Builder, I make a new object of (my own) class BAFoo that tells what number to display when the button is pressed.

Now, I have inspected the files that were made when I created this program, the only interesting ones being BAFoo.*, but I don't see where there is code instantiating the objects buttonToPress or numberToDisplay, nor do I see where the appropriate files (NSTextField.h and NSButton.h) were included. I am new to programming. Can you help me out? Feel free to correct me if I used the incorrect language.
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
You can't duplicate Interface Builder's files using the command-line alone. Interface Builder doesn't generate code. Instead, it creates actual objects, changes their attributes according to the different UI elements you interact with, then serializes or archives those objects to an xib or nib file.

When a program loads a nib or xib file, the opposite occurs: the file data is deserialized or unarchived and interpreted in a way that recreates the object.

Some of the pivotal classes and protocols to do this are NSCoding, NSCoder, NSArchiver, and related.
http://developer.apple.com/library/.../Archiving.html#//apple_ref/doc/uid/10000047i

The advantages of separating the GUI's objects from compiled code should be obvious. First and foremost, it's not necessary to recompile any code in order to modify the appearance of the GUI. The extent to which the GUI can be modified can be quite large. It's entirely possible, given a suitable program design, to completely change the class of some GUI elements without any code recompilation. For example, buttons can be changed into popups, popups into radio-buttons, lists into tables, etc.

If you're new to programming, this may all be over your head.

Maybe I should have asked this first:
What did you expect to see?
Explain why you expected to see that.​
 

bahlquist

macrumors member
Original poster
Oct 6, 2010
41
0
You can't duplicate Interface Builder's files using the command-line alone. Interface Builder doesn't generate code. Instead, it creates actual objects, changes their attributes according to the different UI elements you interact with, then serializes or archives those objects to an xib or nib file.

When a program loads a nib or xib file, the opposite occurs: the file data is deserialized or unarchived and interpreted in a way that recreates the object.

Some of the pivotal classes and protocols to do this are NSCoding, NSCoder, NSArchiver, and related.
http://developer.apple.com/library/.../Archiving.html#//apple_ref/doc/uid/10000047i

The advantages of separating the GUI's objects from compiled code should be obvious. First and foremost, it's not necessary to recompile any code in order to modify the appearance of the GUI. The extent to which the GUI can be modified can be quite large. It's entirely possible, given a suitable program design, to completely change the class of some GUI elements without any code recompilation. For example, buttons can be changed into popups, popups into radio-buttons, lists into tables, etc.

If you're new to programming, this may all be over your head.

Maybe I should have asked this first:
What did you expect to see?
Explain why you expected to see that.​

Well, I want to understand how the code/compiler works. It seems reasonable that I would be able to create a program that does exactly what I just created using Interface Builder, but without using Interface Builder. If I was able to do that (or someone did it for me), then I could examine the code and maybe learn from it. If some of my program is always locked away in .xib files, then I am missing a crucial part of the whole picture.
 

foidulus

macrumors 6502a
Jan 15, 2007
904
1
I think you are making this harder than it needs to be. In Cocoa you can code the entire interface just like you can in Java or almost any other language. Trying to reverse engineer the xibs is going to be much harder and you will get a lot less out of it than just coding your interface.
 

bahlquist

macrumors member
Original poster
Oct 6, 2010
41
0
I think you are making this harder than it needs to be. In Cocoa you can code the entire interface just like you can in Java or almost any other language. Trying to reverse engineer the xibs is going to be much harder and you will get a lot less out of it than just coding your interface.

I am not saying that I plan doing this as a regular practice. I just want to understand what is going on.

Has anyone here ever coded a simple program in with a GUI in Objective C and compiled it from a command line?
 

Catfish_Man

macrumors 68030
Sep 13, 2001
2,579
2
Portland, OR
Sure. It's not hard, it's just a pain in the ass.

Code:
NSWindow *win = [[NSWindow alloc] initWithContentRect:... styleMask:... backing:... defer: NO];
SomeViewClass *contentView = [[SomeViewClass alloc] initWithFrame: ...];
[win setContentView:contentView];
[contentView addSubview: someOtherView];
//more code to add other views, set autoresize masks, set positions, etc...
[win makeKeyAndOrderFront];

This isn't what Interface Builder is doing exactly though. IB-created objects will go through the -initWithCoder: path instead at runtime, since they're being "reconstituted", not created in the first place.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
Well, I want to understand how the code/compiler works. It seems reasonable that I would be able to create a program that does exactly what I just created using Interface Builder, but without using Interface Builder. If I was able to do that (or someone did it for me), then I could examine the code and maybe learn from it. If some of my program is always locked away in .xib files, then I am missing a crucial part of the whole picture.

Look at the contents of main.m - just a call to NSApplicationMain. Read the documentation for NSApplicationMain and all the stuff it calls (which is a lot). At some point a .nib is loaded. Read what "loading a .nib file" means. Instead of loading a .nib file, you can do it all by hand if you like, by calling things like [[NSButton alloc] init...] over and over again, adding subviews to views to create the view hierarchy, setting selectors for actions and so on and so on and so on.

What you could do instead: Write a program with a .nib file and make it run. Then add an "awakeFromNib:" method in the right place, just add an NSLog () first to see that it gets called. When that is done, remove _one_ object from the .nib file, then create it by hand in your awakeFromNib method.

I am not saying that I plan doing this as a regular practice. I just want to understand what is going on.

Has anyone here ever coded a simple program in with a GUI in Objective C and compiled it from a command line?

Definitely not from the Command Line, that is just pain without any gain. I've written code with an almost empty main .nib file, but not without one.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.