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: Tue, 19 Apr 2005 01:11:08 +0200
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
-----------------------------
_______________________________________________
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