On Sep 28, 2010, at 10:47 AM, Shawn Bakhtiar wrote: > Question, why not just derive the camera class from NSWindow?
A camera is not a different kind of window. The only significant reason to subclass NSWindow is to create a new kind of window - not a window for a specific task. > There is no programmatic need for NSWindowController, as an NSWindow is also > an NSResponder (can take all input). The need for NSWindowController is to manage interaction between model-level and view-level objects, as with all controllers. In the original poster’s case I wouldn’t make Camera a subclass of NSWindowController and I *certainly* wouldn’t make Camera a subclass of NSWindow. Instead, I would create a CameraSettingsPanelController subclass of NSWindowController, with a “camera” property to present the Camera for which it presents settings. This is the route Quincey Morris suggested as well. I suspect that the CameraSettingsPanelController class will grow over time, from a class that (say) just implements -init (since it’s likely to use a nib with a fixed name) and a “camera” property, to also implementing logic for saving and loading settings specific to a Camera, managing interaction between the Camera it presents and the views in the panel representing its settings — for example, by acting as an NSTableView delegate and data source for managing drag & drop — and so on. It may not wind up a very “thick” class, but my guess is that in the end it won’t be entirely free of interesting code either. -- Chris _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
