Re: NSDocument-based architecture suiting my NSBundle-based documents case?
Re: NSDocument-based architecture suiting my NSBundle-based documents case?
- Subject: Re: NSDocument-based architecture suiting my NSBundle-based documents case?
- From: Hamish Allan <email@hidden>
- Date: Thu, 21 Apr 2005 02:41:57 +0100
Hi Dirk,
When I re-analyze my design decisions, I come to this conclusion: When
I thought of opening un-annotated audio files to put them in a bundle
where also the to-be-added annotations would be stored, I felt
uncomfortable to *not* make that bundle immediately. That also has to
do with the fact that those individual (sub-document) annotations had
to be stored somewhere. I felt -and I still feel- it would be good to
create an audio file wrapper once you decide upon a new document.
That's similar to Xcode, which creates an actual directory, project
file and other files when you choose New Project.
If I remember correctly, you're not using bundles any more, but
presumably directories instead -- just like XCode. But XCode is
designed that way because the user is supposed to be able to access
individual files within them. If you were originally going to use
bundles, I would guess that your documents are designed to be
opaque/atomic to the user, in which case you should probably persevere
with NSBundle (IMHO a golden rule when writing software is never to
sacrifice the user's convenience for your own). But I am making
assumptions which may be incorrect. Are your documents are more like
XCode project directories, or the XCode project files themselves (which
are bundles containing files with the actual project data)?
Yeah, but that (i.e. make the action that responds to "Create new ...
audio") would mean I have to subclass NSDocumentController, or doesn't
it?
Probably. I don't suppose it would be possible to connect "New" to the
same target as "Open" but give it a different filetype filter?
And what methods are called exactly when the user double clicks a file
in the Finder to be opened in my app? Or (presumably similar) what
happens when the user drags a file into my app?
I would guess: exactly the same ones that are called after the user has
chosen a file in the open menu.
I mean: my application should behave the same way, regardless of the
type of file (pure audio file or my custom wrapper directory): open it
in a window and allow the user to add annotations.
Yep, maybe scratch the idea of "New" and just have "Open" able to open
both filetypes.
And another strangeness I found: when I make a delegate of NSApp
respond to -application:openFile: (like I said I was gonna try out in
my last mail), I NSLog something and return YES, the opposite of what
I expected happens: nothing. I doesn't open the file. But when I
remove this method from the delegate, it opens files. Maybe somebody
else understands more about this.
I believe that when a delegate responds to a message like this, it
travels no further up the responder chain; whereas if the delegate had
not responded, something further along the chain would have handled it,
which in this case is what actually opens the file.
May my application quote you on that? ;-)
But of course. My pleasure.
Best wishes,
Hamish
_______________________________________________
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