Re: NSWindowController usage question

FROM : Chris Giordano
DATE : Thu Oct 14 16:52:35 2004

Rick,

On Oct 14, 2004, at 10:09 AM, Ricky Sharp wrote:

> I'm writing an application "shell" to serve as the foundation of all
> my apps.  Such apps are all kiosk-like and are made up of one and only
> one window.  The contents of the window will be dynamically set to
> represent "screens".
>
> As a simple example, consider the following:
>
> Upon launch, you get a window whose contents represent "screen 1". 
> Say that the screen contains a single button "Go to screen 2". 
> Clicking that button will unload the current content view and load the
> new one which reprents "screen 2".
>
> Here's what I'm planning to do:
>
> MainMenu.nib will contain the owner (NSApplication), AppController
> (delegate of the owner) and the main menu.
>
> Separate nibs will be created; one for each of my "screens".  These
> nibs will contain the owner (custom NSWindowController), NSPanel
> containing all the UI, and a custom controller (delegate of the
> panel).  The nib that represents the starting screen (i.e. the screen
> that is shown when the app is launched) will always have the name
> MainScreen.nib.
>
> In my app controller, applicationDidFinishLaunching: will manually
> create an NSWindow (my singleton window) and center it.  I then want
> to load the MainScreen nib, access the NSPanel's contentView and set
> that as the content view of the singleton window.
>
> I plan on having the following static method in my AppController to
> provide such a "go to screen" function:
>
> + (void)gotoScreen:(NSString*)screenName
>
> The implementation would then need to...
>
> - load the nib with the given name and intantiate the window controller
> - window controller loads the panel
> - panel's content view is obtained which is then set as the content
> view of the main window
>
> But here is where I'm wondering if I need to have either an
> NSWindowController object in all these nibs.  Would I be better served
> in having these nibs have an owner which is the controller of the
> screen (i.e. delegate of the panel)?  Put another way, is having a
> window controller here just an extra layer that really isn't needed? 
> I imagine that without the controller, the implementatio nof
> gotoScreen: would be more like this:
>
> - load the nib with the given name
> - somehow access the panel
> - etc.
>
>
> 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.
>
> Hope this all made sense,
>
> Rick Sharp
>


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.

chris