Re: Utility window architecture question
Re: Utility window architecture question
- Subject: Re: Utility window architecture question
- From: Chris Giordano <email@hidden>
- Date: Fri, 17 May 2002 14:28:55 -0400
Brock,
It looks a lot like the OAPreferences framework is being used in
OmniGraffle. It looks a lot like the preferences window in OmniWeb, too.
Having looked at the OAPreferences framework (in an attempt to see how
they did things while trying to implement something which ended up being
very much like theirs, but it was a really good learning experience...),
the general idea seems to match yours fairly closely -- you create a
number of separate preferences objects (the panes), and there is a
controller which handles the loading of the appropriate pane into the
view, etc.
It sounds like this would be a compatible approach. When I built my
version, each pref pane had its own controller and nib file. The panes
were loaded by the main controller, and the main controller kept track
of the pref panes by storing the controller (in a dictionary in my case,
since each pane had a name which was the key for the dictionary), which
in turn kept track of the interface, etc. When I needed to load a pane,
given the name of the pane to load, I would look up the pane in the
dictionary, get the controller for the pane, get the stored view
(interface), and put this into my preferences window.
I'd take a look at the OAPreferences framework -- it's in OmniAppKit
(info at
http://www.omnigroup.com/developer/sourcecode/, download from
http://www.omnigroup.com/ftp/pub/software/MacOSX/Source/Frameworks/),
and the documentation on NSPreferencePane
(
http://developer.apple.com/techpubs/macosx/AdditionalTechnologies/PreferencePanes/
Reference/ObjC_classic/Classes/NSPreferencePane.html or do a search for
"Preference Pane" on developer.apple.com and you'll get a bunch of hits
with useful info). You might not want to do pref panes exactly, but the
idea sounds about right.
chris
On Friday, May 17, 2002, at 12:14 PM, Brock Brandenberg wrote:
I have a number of utility windows in an application that are used as
object inspectors. What I would like to do is to combine them into a
single panel very much like what Omni does in OmniGraffle, but I would
like to avoid bringing all of the associated code into a single window
controller and simply swapping the content view of the window. Separate
windows have the advantage of good code separation, each window having
a custom window controller complete with outlets and actions that are
unique to that window. When using the view swapping method, I feel like
I need all of the outlets and actions in the same window controller,
which leads to too large of a nib file and too much code in a single
window controller to be easily managed (the inspectors each have many
controls).
My question is, does anyone have a suggestion for a good code
architecture for a panel that has its content view swapped out at
runtime? For example, should I be creating a view controller for each
custom view that is responsible solely for that view's contents, then
load and unload each controller and associated nib as appropriate?
Thanks,
Brock Brandenberg
----- industrial design @ bergdesign.com ------
_______________________________________________
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.
_______________________________________________
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.