On Feb 16, 2015, at 9:24 AM, Dave <d...@looktowindward.com> wrote: >> I recommend that you follow the advice in this article: >> <https://www.mikeash.com/pyblog/friday-qa-2013-04-05-windows-and-window-controllers.html>. > > Thanks for this, it seems to be saying there is no need for a separate Window > Subclass and that the Window Controller Subclass contains all the code needed > to drive the window.
It's relatively rare to need to subclass NSWindow. Usually, you can achieve whatever behavior you need with a standard NSWindow or NSPanel and the window's delegate. You typically want a custom subclass of NSWindowController to be responsible for the window (and the memory management of the top-level objects in the window NIB). It's convenient and common for the window controller to also be the window's delegate. > I’m a bit confused of when to use an NSWindow and when to use and > NSWindowController? Well, NSWindow is an actual GUI object. If you don't have a window, then there's nothing for the user to see or interact with. NSWindowController is, as its name implies, a controller. You typically use both. The window controller creates and controls the window. > The way I had thought to do this was to have: > > LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib > files. You never want a NIB for the window controller that's separate from the NIB containing the window. You want a single NIB for the window which the window controller will load and be the owner of. The NIB will *not* "contain" the window controller. The File's Owner placeholder in the NIB represents the window controller, but the window controller will be created before the NIB is loaded and will, in fact, be the thing which loads the NIB. > Is this the best approach? Or it is better to put the code in the > LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? It makes no sense to discuss where some unspecified code goes until you know what the code is for. As I say, usually there's no need to subclass NSWindow. You would have a custom window controller class and a NIB that encodes the state of the window and at least some of its views. The NIB might also encode some auxiliary controller objects, like an array controller. You would only create a custom subclass of NSWindow if the normal mechanisms (window controller, window delegate) don't meet your needs. Don't do it preemptively. > Or instead of using NSWindowController and NSWindow should I be using > NSWindowController and NSViewController? Well, there will always be a window or otherwise there's nothing for the window controller to control and nothing to contain any views that might be controlled by any view controllers. You may find it convenient to organize your project with view controllers for some important views within your window, but that sort of depends on how complex your window and its view hierarchy are, and whether you'll be swapping views in and out or reusing views in multiple contexts. Again, it doesn't make sense to pick a design architecture in the abstract. You design the architecture based on the specifics of your app. > I’m really confused how to lay this out and want to start off on the right > foot. For starters, just follow the advice in that article. Create a custom subclass of NSWindowController. Create the NIB to encode the window's configuration and view hierarchy. Don't go more complicated than that — custom window classes, separate view NIB with view controllers — until you need to. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
