Re: NSWindowController usage question
Re: NSWindowController usage question
- Subject: Re: NSWindowController usage question
- From: Chris Giordano <email@hidden>
- Date: Thu, 14 Oct 2004 10:52:35 -0400
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
_______________________________________________
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