Re: Inspector Windows
Re: Inspector Windows
- Subject: Re: Inspector Windows
- From: Chris Hanson <email@hidden>
- Date: Wed, 7 Aug 2002 16:27:03 -0500
At 11:01 AM -0700 8/7/02, Alan wrote:
How do you make inspector windows that inspect any document in a
Cocoa document-based application?
I developed an inspector architecture for a document-based
application I'm working on. It doesn't just enable the inspection of
documents; rather, it enables the inspection of whatever the current
selection is.
When the user's selection has changed, it broadcasts a "selection
changed" notification. This notification has the current document as
its object and a userInfo dictionary containing the selected object
under the key "selection". (If there is no selection, I just leave
the selected object out of the userInfo dictionary.) I consider the
selection to have changed when the user brings a new document to the
front, closes a document, etc. as well, so that the inspector state
is always in sync.
Separately, the application has a shared inspector controller object.
The inspector controller manages the inspector window, and subscribes
to selection changed notifications. When it receives one, it gets
the selected object from the notification and, if one exists, checks
to see if it responds to -inspectorClass. (If no selection exists,
it uses a default inspector class.) Each inspector class is a
subclass of Inspector; the class retrieved from the selection is used
to create a new inspector object for the current selection.
An inspector object always has a reference to the inspector
controller that created it and the object it is inspecting, and only
lives for the lifetime of the current selection. (In other words,
inspector objects are lightweight and aren't reused.)
When an inspector object is created by the inspector controller, the
inspector controller also loads a nib of the same name. In the
inspector object's -awakeFromNib, it retrieves a view and tells the
inspector controller to put it in the inspector window. It also
fills in the contents of this view with information about the
selection.
All this means that if I want to add support for a new class of
selectable object in the inspector window, all I have to do is (1)
make sure a "selection changed" notification is broadcast when an
object of that class is selected, (2) make sure the object responds
to -inspectorClass with an appropriate subclass of Inspector, (3)
create a subclass of Inspector, and (4) create a nib file for the
inspector view. The entire process, if I just want to view an
object's properties in a nice human-readable format, takes about
10-20 minutes. And it's completely general: There's nothing specific
to this particular application in the mechanism at all.
The one part I haven't wired up yet is the ability to change
properties in the selection. I have some stub methods but they don't
do anything yet. I'm not 100% sure how I want to architect it yet.
After all, changes made in the inspector need to propagate back to
the document. It would be easy to do with another notification, but
I'm not positive that's how I want to go with this design yet.
-- Chris
--
Chris Hanson | Email: email@hidden
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
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.