I created a preference pane, in the same XIB as my application window. I was able to easily link the “Preferences” menu item to the preferences window, and open it up. Great!
But I am thinking that it would be better to put the preferences stuff into its own XIB. I created the preferences window in its own XIB and I am now at a loss for linking the two together.
I have a feeling that this is probably much simpler than what I have tried…
It’s actually reasonably complicated. The “standard” way is to make a new class that subclasses NSWindowController, and in it you implement -initWithWindowNibName:. You set the File’s Owner of the nib to this class, and it’s where any methods called from window widgets live. You also implement -awakeFromNib in your window controller, using it to do any set-up and to open the window. To show the window, your main class makes an instance of the window controller if there is not one already, and calls -showWindow:.
Hmm, ok. Yes that is reasonably complicated.
Would these new classes be implemented in Obj-C then?
I wonder if it’s worth the extra effort for such a small project.
I just found your website, I will check out your books!
It can be done in ASObjC, but…
Probably not. The downside to putting it in Main.xib is that the nib theoretically takes a little longer to load, but in practice you’re not going to notice any difference. If a project is big enough to warrant the exercise, it’s often getting too big for ASObjC.
Hello.
I like to fork out the code even for a view that is to go into the main window, into a separate controller/xib file. I am lazy, so I did this when I ported some IOS tutorials over to OSX. I have done that since, because it makes everything easier, when the code for the view/window is segregated. When you partition like this, then you get a logical unit of functionality to relate to, which at least I find to be better than having an over-crowded App delegate.
I don’t see this as something that has to do with the size of the project, nor that it implies that the project will be to big for ASOC. 
On the contrary, it at least simplifies working with it, admittingly I haven’t done anything like this in ASOC, but I can’t see that this will stall any project, not as long as you use as much of bindings and other Cocoa goodness you can leverage upon from ASOC.
One thing however: it seems most logical to me to use the window of the Main.xib file for the preferences, since I feel that to belong to the “inner tier” of the app, together with the app delegate and all that.
Then I suggest you try.
The idea of an over-crowded app delegate is very much a matter of the size of a project.
One of the differences with ASObjC is that passing AppleScript objects between classes involves an extra layer of conversion – messages always pass Cocoa objects, so passed arguments need to be converted. As you add classes, it’s another layer of code.
That said, there’s certainly nothing wrong with it. It’s just an extra level of complexity that adds little for smaller apps. The days of worrying about loading times for nibs are long gone.