On Aug 3, 2016, at 07:56 , maximilian.schm...@mto.io wrote: > > Is it possible for the NSDocument to know about the audio files in it’s > package folder and handle them like they belong to it without wholly > representing them in the model?
I don’t believe there’s any good solution based on a unified document package. That’s because the NSDocument semantics are based on the reasonableness of reading-then-writing the entire contents of the document at save time, and it’s not reasonable in your scenario. I think we tend to think, as developers, that if we use NSDocument for large asset-based editors, users will want to blithely copy and move their documents as if they were Pages documents. I’m not sure this is true. Instead, if there are a lot of bulky assets to collect, it feels quite natural for the bulk of the data to be in a fairly fixed location, especially it that data is more like a cache than like editable data. I’ve tried a couple of alternatives over the last few years. (None has ended up in a released product yet, so I can’t vouch for user satisfaction.) One approach is to ask the user via NSSavePanel, after creating a new document, for a folder location to use for “working storage”. You then create a file package at that location that holds the copies of your asset files. The document, now much smaller, has a URL reference to that package, so copying or moving the document doesn’t affect the asset package. If the user wishes to transfer the document to (say) a thumb disk or another Mac, then the user is responsible for copying the matching asset package, too, and your code is responsible for asking where to resolve the “broken” document URL reference at the other end. Another approach is to create a free-standing asset repository (in, say, your Application Support subfolder), and have the user import assets there *independently of* any particular documents. These assets can be organized into “projects” and documents then created making use of the assets from one or more projects. Or you can do something intermediate between these two extremes. (E.g. allow the user to create working storage folders at any desired location, which allows the big files to be on a separate volume.) Whatever you do, you might need an Export menu item that packages up everything a document needs, for cases where the entire project need to be moved to (say) another Mac. Maintaining references between documents and assets is a fair amount of fiddly work (because you have to deal with various kinds of broken references), but it’s a lot less hinky than trying to mess with the NSDocument behavior directly. FWIW _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
