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: Dirk van Oosterbosch <email@hidden>
- Date: Thu, 21 Apr 2005 01:25:10 +0200
Hi Hamish,
thank you for commenting on the design paradigm I was taking. I won't
guarantee that I will make the application behave exactly like you
propose ;-) but it is still really good, to hear some unexpected
feedback, shaking by (presumed thoroughly thought through) plans.
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.
But I must agree with you: where you say that creating such a place to
store, does not imply a decision about the location of the audio file
just yet. That indeed can also be decided by the user / system on save
time.
On 19-apr-05, at 19:50, Hamish Allan wrote:
I think you make some assumptions here which it might be helpful to
revisit. There is no reason to put the audio file inside the bundle
(therefore nor to display that modal dialog) until the user selects
"Save as...". Opening an audio file is really more like "Create new
document from imported audio" than "Open" per se. To me it would make
sense to put "New" back in the file menu and have it trigger an open
dialog for audio filetypes. I think this would give the user a much
better sense of what is going on.
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? 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 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.
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.
--something like "Do not copy audio" with a tooltip of "If you choose
this option, you must ensure that the original audio file remains in
its current location from which it will be referenced."
May my application quote you on that? ;-)
Thanks again for the paradigm-shifts,
Best,
Dirk
_______________________________________________
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