Re: Crazy Behind the Scenes Hard-wiring in AppKit?
Re: Crazy Behind the Scenes Hard-wiring in AppKit?
- Subject: Re: Crazy Behind the Scenes Hard-wiring in AppKit?
- From: "R. Scott Thompson" <email@hidden>
- Date: Thu, 9 Dec 2004 22:45:57 -0600
On Dec 9, 2004, at 8:27 PM, Seth Willits wrote:
Realizing that I couldn't use existing document classes to accomplish
tabbed documents, I started writing my own classes from scratch and
have been working on it off and on when I have a few minutes of free
time. Today I just noticed that if use the Document Types list in the
target's Properties view, somehow AppKit watches for instances of
those classes to be created and automatically calls methods on those
classes (methods like makeWindowControllers,
_handleDocumentFileChanges, isDocumentEdited), regardless of whether
they're subclasses of NSDocument or not.
How weird is that? Or is it at all?
Apart from the fact that the idea of having multiple documents in the
same window reeks of MDI frames and makes me cringe (I'm not a fan of
tabbed documents... except, perhaps, in browsers), I don't find it to
be particularly weird. Given the fact that Objective-C is a
dynamically dispatched language, I don't find it any weirder than
having the NSTableView data source methods called on a class that
hasn't inherited behavior from some theoretical superclass of all table
view data sources.
Cocoa expects any object that claims to be a document to respond to
certain messages. It might be nice, however, if those messages were
documented somewhere. Is the system throwing "Doesn't respond to"
exceptions or is it just innocuously calling messages on your class?
I simply want to make a group of classes so that I can contain
multiple documents within a single view, but on my path to doing so
I'm finding a couple of short-circuit paths that AppKit is taking to
make normal document applications simpler to write. However, it seems
that they are imposing limitations on my own application which has
nothing to do with the standard document classes.
I suspect that some features of the architecture are just looking to
your classes to provide information that NSDocument usually handles
"for free".
I'm afraid that you are fighting one of the classic battles between
applications and frameworks. I've worked with quite a few frameworks
over the years and it always seems that when you want to do something a
bit different that you have to fight against the framework to get it to
happen.
(something different like creating tabbed documents in spite of the
fact that they are a blight on the face of decent UI and particularly
out-of-place on the Macintosh :-) )
If you can identify what services are actually calling for that
information, you might be able to kill off and replace those additional
services. Unfortunately, that means more work for you :-(
Scott
P.S. Please take read comments against tabbed documents as
good-natured ribbing and not actual criticism. You like 'em, then more
power to you!
_______________________________________________
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