Re: NSWindowController usage question
Re: NSWindowController usage question
- Subject: Re: NSWindowController usage question
- From: Ricky Sharp <email@hidden>
- Date: Thu, 14 Oct 2004 11:14:16 -0500
On Thursday, October 14, 2004, at 09:52AM, Chris Giordano <email@hidden> wrote:
>
On Oct 14, 2004, at 10:09 AM, Ricky Sharp wrote:
[ most of original e-mail snipped]
>
> I've been searching for sample designs similar to what I'm trying and
>
> cannot find any. All references either deal with the NSDocument
>
> architecture or applications that have multiple windows. Again, I'll
>
> only have a single window, but it's contents can come from many
>
> different nibs.
>
>
I did something similar a while ago that dealt with preferences in a
>
similar manner: multiple bundles, each with an interface, displayed in
>
a single window. My model was System Preferences, but at an
>
application- or document-level, but this seems to fit your situation
>
somewhat closely. (Or, alternately, the System Preferences/preference
>
panes model may be an approach to look at given that it is similar in
>
nature to yours. However, in my case...)
>
>
I had preference pane bundles that would be loaded, and a preference
>
pane class that allowed me to access, among other things, the view to
>
be displayed. This class served a role very similar to
>
NSWindowController in that it managed the viewable content from the
>
nib. It didn't involve a window, though; the nibs only had a view in
>
them. (It also allowed me to give the panes identifiers, names and
>
group them much like in System Preferences, but that's not necessarily
>
relevant to your situation.) In your case, it may or may not be
>
feasible to have this class serve as both the access point to your view
>
as well as the "custom controller (delegate of the panel)" role. I
>
believe that I did essentially this - my class did the work of taking
>
the relevant settings and displaying them in the interface, and then
>
taking the values from the interface and handing these back to the
>
application when the pane was closed, and any other work that the
>
interface required (NSTableView data source, etc.).
>
>
It seems both the NSWindowController and the alternate approach you
>
outline above are similar in that there is a class responsible for
>
managing the contents of the nib file and through that class you get
>
the interface for the new screen. However, as you note, the
>
NSWindowController involves an extra window. You're looking for the
>
content view, so just have the content view in the nib.
>
>
Just my two cents. Hope this helps.
It definitely does help, especially the description of how what I want it similar to your prefs architecture. I agree that since I only want the content view, that the window controller seems to be an extra piece that isn't needed. Thus, I'll do that "alternate" approach.
I'll be writing code for this soon which will either prove/disprove my design. Although I'm much now much more confident that it will work and is a good approach.
Thanks,
Rick Sharp
Instant Interactive(tm)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden