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: Tue, 19 Apr 2005 18:50:32 +0100
Hi Dirk,
On Tue, 19 Apr 2005 01:11:08 +0200, Dirk van Oosterbosch
<email@hidden> wrote:
Well, the point is, by opening the audio file *should* become part of
the bundle. The bundle is the only file type the user can edit and have
open as document. But the user should also be able to double click or
drag a un-annotated, normal audio file in, or choose open from the
menu. In those cases first a modal should be run (see #2) and then the
audio file should be put inside the bundle and the bundle should be
opened.
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.
The only difference there seems to be, is that there is no need for the
audio file to be loaded in. I just want to quietly move the file inside
my wrapper. So can I do without calling super and just setFileType and
setFileName in the readFromFile method? Or do I have to create multiple
hierarchical subclasses of NSDocument? (MyBaseDocument: NSDocument &
MyWrapperDocument: MyBaseDocument: NSDocument)
The decision of whether to reference an external audio file or to copy
it into the bundle can be made at save time. I would also be much more
inclined to make it a checkbox in the save dialog (which remembers what
you wanted to do last time) rather than a modal dialog (which annoys
the user by popping up every time) -- 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."
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