> On Aug 3, 2016, at 11:51 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Aug 3, 2016, at 07:56 , maximilian.schm...@mto.io > <mailto: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.
Hey Quincey! I thought his was the case but wasn’t a 100% sure. Thanks for clarifying. Makes total sense, but I thought there might be little features to help me. > 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. For a single user that might very well be the case. But when working in a team on a professional level (like I have for many years), when the document is copied around many times from Mac to Mac, to and from a shared server, the asset-management has to be as simple, transparent and bulletproof as possible. Loosing audio files is the worst. It took hours for us to figure out what went wrong in Pro Tools and thankfully we always recovered them. It doesn’t happen often, but with a fixed deadline rushing towards you, you could potentially loose your job. That’s why I force the user to have a new copy of the imported audio file and not just a reference to where the original is located. I want an easy solution at the cost of storage. I’m also looking into completely locking the audio files to prevent the user from tinkering with them. > 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. There are too many possibilities for the user to mess this up. And sometimes things have to move fast when working. So that option’s out. But a good idea to keep in mind for other projects :) > 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. Yes, I thought about that. But it falls into the same category as the above and below. > 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. That’s also a reasonable approach for many applications. But I want there to be no hidden obstacles when sharing your project with others. When he copy-pastes the project file, the user might very well think that he created a working project and I believe this absolutely should be the case. > 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. Yes. I now believe that’s a rocky path I’m getting onto. But better it’s hard for me than for the user :/ Thanks for your input! > FWIW > Very worth! _______________________________________________ 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
