Re: [newbie] Handling a preferences window
Re: [newbie] Handling a preferences window
- Subject: Re: [newbie] Handling a preferences window
- From: Jeremy Dronfield <email@hidden>
- Date: Tue, 1 Oct 2002 15:03:25 +0100
On Tuesday, October 1, 2002, at 12:19 am, James DiPalma wrote:
Your original post (which I overlooked) makes these points:
A preferences controller should be a subclass of NSWindowController
Yes, I did say that. It was an overly prescriptive. I should have said
that it would "probably be best" to make it a subclass of
NSWindowController (for newbie reasons - more on that below).
I think I now understand what you are suggesting:
1. Make a subclass of NSWindowController and instantiate it in
MainMenu.nib
2. Connect your preferences menu item to showWindow:
3. In NSWindowController's init method call initWithWindowNibName:
4. In NSWindowController's init method call
setWindowFrameAutosaveName:
I like this suggestion. It may or may not be how you would implement
it, but it accurately takes your suggestions and preferences for
NSWindowController and shows how to implement a solution to this post's
original question.
Closer, but still no cigar. What you've actually done here is conflate a
selection of suggested solutions for different situations into one
design. For the full selection, I refer you back to the last-but-one
paragraph of my last post.
I would like to see more information about: what your solution for
loading a preferences window is
Quite simple: I would (indeed have, in my own apps) put the window in
its own nib, with a window controller subclass acting both as the
window's controller and the nib file's owner. This brings us right to
the nub. In your last post, my liking for window controllers was
questioned as though it were ... well, not exactly a perversion of
Cocoa, but certainly an idiosyncratic practice (you keep referring to it
as *my* design) which I ought to justify. I'm not going to explain
myself: instead I'll let Apple do it for me (for the benefit of newbies,
since I presume you, Jim, must know this stuff inside-out):
From Programming Topics, section on Using Multiple Nib Files:
"There are two main ways to open a nib file.
Use NSWindowController, which loads a window and its contents from
a nib file and then manages that window. See the class description of
NSWindowController for additional information.
Load it explicitly with the method -[NSBundle loadNibNamed:ower:]"
From the class description of NSWindowController:
"The relationship between an NSWindowController (or, simply, a window
controller) and a nib file is important. Although a window controller
can manage a programmatically created window, it usually manages a
window in a nib file. The nib file can contain other top-level objects,
including other windows, but the window controller's responsibility is
this primary window. THE WINDOW CONTROLLER IS USUALLY THE OWNER of the
nib file, even when it is part of a document-based application.
Regardless of who is the file's owner, the window controller is
responsible for freeing all top-level objects in the nib file it loads."
(capitals added)
I would only add, with reference to your statement that window
controllers are "only useful for nib's with windows" that I've never
suggested using them in any other way. Your further assertion that their
use is undesirable because they "can prevent newbies from learning
simple techniques that help them with other nib files" is arguable but,
I think, probably not true. I'll explain:
why subclassing NSObject is for experienced developers and not newbies.
"For the MORE experienced" is what I said - i.e. someone with at least a
basic grasp of application architecture. For those who are completely
new to Cocoa, I maintain that it's probably best to use a window
controller as described in the documents quoted above. This is for the
simple reason that, at first, Cocoa seems bewilderingly complex (I speak
from recent experience). Therefore, the existence of a class called a
"window controller", which contains special methods for dealing with
windows, provides a degree of intuitive consistency which is reassuring
to a beginner. It does what it says, does it all in one place, and has
everything the dew-fresh newbie is likely to need already built-in. In
my humble still-a-newbie opinion, I think NSBundle is probably best left
until a *little* later in the learning curve (the natural place to begin
studying it is probably when learning to access resources in the
application bundle). In evidence, I submit the fact that Mike Beam's
otherwise excellent Cocoa tutorials use NSObject subclasses as
controllers, and that this caused me quite a bit of confusion at first.
It kept me ignorant of window controller methods, and also resulted in
making my efforts to understand how windows, window controllers and
other classes fit into Cocoa application architecture much more
difficult than it needed to be.
-Jeremy
========================================
email@hidden // email@hidden
The Alchemy Pages:
- fractious fiction at
http://freespace.virgin.net/jeremy.dronfield
========================================
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.