Re: NSDocument-based architecture suiting my NSBundle-based documents case?

FROM : Dirk van Oosterbosch
DATE : Tue Apr 19 01:11:08 2005

Hi Mike,

Thanks for responding.
I guess I should have changed the title of this thread since I am not 
using NSBundle anymore, but the issues stay the same.
And sorry everybody for asking a bunch of stupid questions, after just 
reading the docs. I should have just tried some. My bad. Luckily I am 
now, and I found out for one that I should not use NSBundle to open the 
bundle(!) But still ...



On 18-apr-05, at 16:50, Mike Ferris wrote:

>> Now my questions about the NSDocument-based architecture:
>> 1. The NSDocumentController should NOT create new empty files in my 
>> case. (There is nothing to annotate when there is no audio.) How can 
>> I disable the newDocument: behavior?
>>

> In your application delegate implement 
> -applicationShouldOpenUntitledFile: and return NO.
>

I believe you got me wrong. This delegate 
-applicationShouldOpenUntitledFile is deciding whether or not to open a 
empty document when the application launches. But I don't want to open 
any empty document at all.
I removed the "New" menu item from the MainMenu. Is this sufficient?


>> 2. The NSDocumentController (or the one in control) should first be 
>> displaying a modal window when the user opens an audio file. From 
>> where / when can I call this modal and should I then have the modal 
>> call the NSDocumentController openDocument: ?
>>

> In app delegate implement -applicationDidFinishLaunching: and run your 
> open panel there.  Maybe by calling [[NSDocumentController 
> sharedDocumentController] openDocument:nil]...  But you may also want 
> to ask first whether the user wants to create a new document and open 
> an existing one.


I did try this out yet. Maybe I should first. But again, I am under the 
impression you got me wrong. The -applicationDidFinishLaunching 
delegate method is called when the *application* launches, and I am 
looking for a method to be called when (or rather) before a document is 
opened. I also saw the -application:openFile: delegate from 
NSApplication, but that one also only is called when the application 
launches (by a user double clicking a file).
My point is that I want to warn the user when he or she opens a 
un-annotated audio file (because this file will be moved inside a 
wrapper, and for the user that looks like the file is altered). Should 
I then call this modal from -readFromFile ?


>> 3. The "save as" behavior should also be disabled or first present 
>> the user with a sheet. But probably when I found the answers on 1. & 
>> 2. the answer on this one is there as well.
>>

> [snip] Do this by catching the -newDocument: action in your app 
> delegate


How would I do that? Is -newDocument: a delegate method? Of 
NSDocumentController?


>> 4. It would be rather nice if the user could save individual 
>> annotations. However, I fear that this is really breaking the 
>> NSDocument architecture. (I would be a bit like in Xcode) But then I 
>> need a "Save" (single annotation), "Save all" (all annotations) and a 
>> "Save all wrappers" (comparable with "saveAllDocuments:). How could I 
>> do that? And how would you guys advice me on this?
>>

> This would be a bit weird...


Yeah, that's what I was thinking. But I like to indicate the user that 
a particular annotation was modified, by making it "dirty". But maybe I 
should just implement only that (displaying the annotation icons that 
are editing with a grey overlay.)

> Xcode has a multi-level document scheme


That's the word I was looking for :-)

> You should think hard about how much sense it makes for the user to be 
> saving pieces of what is a single document to them.


Indeed.


>> 6. From the documentation I read that NSDocumentController 
>> differentiates between different files to be handled by different 
>> NSDocument subclasses. I have different file types that can be 
>> opened: audio files and my own annotated-audio-file-wrappers. But 
>> does this apply to me? Or can I also just check for the file type in 
>> -readFromFile? (which looks like getting heavier and heavier.) 
>> Moreover it seems that -readFromFile is a little late to check for 
>> the type and decide what to do. Can I check for that filetype 
>> earlier? (sorry to repeat parts of question 2. here.)
>>

> Is the audio file part of your bundled document?  Or is it just 
> referenced?


The default behavior should be the former, but in the end I have the 
user decide.

> Does it have separate UI?


How exactly? Yes, I supply the user with controls to play the audio, is 
that your question? But the user can not edit or modify the audio file, 
but you didn't ask that, did you?

> If it is part of your bundle, then it should all be one type. 
> Otherwise it should be two.  If you have two types in your Info.plist 
> then the document system will figure out (based on file extension or 
> type) which NSDocument subclass to create for a given file.  Then, 
> your NSDocument subclasses can make finer distinctions if necessary 
> (say .mp3 vs. .aiff vs. .wav for audio files).


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 I'll use one NSDocument subclass, and have all decision made in 
readFromFile:.I should still try that though.


>

>> 7. In the NSDocument FAQ ( 
>> http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/
>> Tasks/FAQ.html ) it says "If you want to automatically convert them 
>> to be saved as your new type, you can override the readFrom... 
>> methods in your NSDocument subclass to call super and then reset the 
>> filename and type afterwards." What exactly does the abstract 
>> implementation of NSDocument do when I call [super readFrom ...]? How 
>> can I tell it to deal with my wrapper format, or how why should I 
>> call super? I am confused.
>>

> It will ultimately cause whatever pair of methods you implemented 
> above in #5 to be called.  The idea here would be relevant for you if 
> audio files are to be part of your bundle, or if the only reason you 
> open audio files is to make an annotation document and there's not 
> really any separate UI for the audio file.  What it suggests is that 
> you can make a document so that if it loads a file (a raw audio file, 
> for example), that after reading the file and creating a new 
> annotation document backed by that file, you could rename and retype 
> the document to be an annotation bundle.


Indeed, that's what I want.

> More concretely.  Let's say you allow the user to load 
> ~/Documents/MySong.mp3 and you want that action to basically create a 
> new annotation document for it.  In an override of readFromURL:ofType: 
> and readFromFile:ofType: you would first call super.  this would 
> eventually cause your -loadFileWrapperRepresentation:ofType: to be 
> called to load the file... you would create an empty annotation 
> document backed by the sound file.  Then, back in the readFrom... you 
> would call [self setFilename:@"~/Documents/MySong.annotationBundle"] 
> and [self setFileType:@"MyAnnotationBundleDocumentType"].  Now, the 
> first time the user saves, it will be to a new file wrapper next to 
> the original sound file.


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)




>> 8. I want to use several different nib files for the different 
>> annotations edit interfaces, but I want to put them all in one 
>> window. (as subview of a tabView or splitView).

>
> You might want to look at MOKit's MOViewController for a solution that 
> allows you to have different controllers for different bits of a 
> single window (different tabs of a tab view, different splits of a 
> split view or whatever.)  http://mokit.sourceforge.net


Ah, great.

Thanks a lot!
dirk



-----------------------------
Dirk van Oosterbosch
de Wittenstraat 225
1052 AT Amsterdam
the Netherlands

T ++ 31 20 7765565
M ++ 31 6 48401910
W http://labs.ixopusada.com
-----------------------------