Re: NSDocument app: combine multiple file contents to open one window instead of multiple windows
Re: NSDocument app: combine multiple file contents to open one window instead of multiple windows
- Subject: Re: NSDocument app: combine multiple file contents to open one window instead of multiple windows
- From: Kevin Perry <email@hidden>
- Date: Fri, 06 Apr 2012 09:37:19 -0700
Unless I'm mistaken, I don't think Gilles is trying to create a "multi-document window" interface like Xcode or Preview. It sounds like he wants a single window with a single view (or set of related views) that simply displays the contents of multiple files in aggregate.
If that understanding is correct, then NSDocument is not the right model here. NSDocument is very specifically about representing a single file or file package on disk and encapsulating the algorithms for both writing to and reading from the contents of said file or file package on disk. It is not built to represent the contents of multiple independent files.
Attempting to shoehorn NSDocument into this use case will buy you very little and give you many problems. You're much likely better off using NSOpenPanel, NSWindowController, NSFileManager, and NSData directly to open and display contents of user-selected files.
On the other hand, if your app creates a visualization that you want to be able to save, modify, reopen, etc., then NSDocument is likely what you want, as long as you realize the difference between "opening documents" and "importing files into a document". The "documents" your app would deal in would be a custom file type that your app defines and creates. Files or file packages of this type would contain all the data necessary to reconstruct the visualization when reopening the document including references to or copies of "imported" files. The files that are "imported" into the document would not have NSDocument instances of their own (unless you were creating something like Xcode's document-within-a-document model). You're still likely going to need to use NSOpenPanel, NSFileManager, and NSData yourself to handle importing these files.
-KP
On Apr 6, 2012, at 9:13 AM, Kyle Sluder <email@hidden> wrote:
> On Apr 6, 2012, at 8:29 AM, Gilles Celli <email@hidden> wrote:
>
>> Versions ? Well here in my case for now I don't need it for my application since it's kind a viewer / visualizer of the data, I'm not editing or changing anything
>> to the file…it's a like a PDF viewer but here for data / graphs.
>
> Fair enough. But you do need to deal with other apps using Versions and file coordination against the files you have open. If you don't follow NSDocument's standard windowing paradigm, it can't perform its normal behavior (like throwing up a sheet alerting to the user that a file has changed).
>
> Or hell, maybe it can. You might be able to use -windowForSheet to point NSDocument at the shared window.
>
>
>>
>> Maybe you got me wrong but it's simply to append the file's contents that the user selected in the "Open Panel" and put these selected file contents
>> (=NSString *fileContent1 + *fileContent 2 etc.) to one big appended NSString *multiContent, then of course call makeWindowControllers
>> to open the NSDocument Window.
>
> I think you will not want any of your documents to own your window; the window should be owned by the app and -makeWindowControllers would do nothing. You can monitor your NSDocumentController to determine whether to open or close your shared window.
>
>>
>> The advantage of using NSDocument are multiple, and mainly printing to PDF works great etc. so it should be possible (since it's possible on Windows XP ;-)
>
> Of course you can do pretty much anything on OS X that you can do on Windows. But OS X's frameworks are designed to discourage bad decisions. The bias inherent in the frameworks produces a consistency across apps that users appreciate.
>
> Just because something is easy on some other platform does not mean it should be easy on OS X.
>
> That said, it sounds like you have a decent use case that won't fight the framework too badly.
>
> --Kyle Sluder
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden