>> I've opted not to make >> the intrusive changes (for now) that have little or no benefit to an >> end user, and probably are in fact detrimental to usability. > > How so? The users would not know about what is going on under the > hood: they would simply open the "main" document, as before. So how > would that affect usability?
My application allows the user to insert photos, video, and audio into their document. It keeps links (in the form of local file URLs) to the files. Under sandboxing, they have far more limited choices of where they can get their source files. For instance, the non-sandbox version allows them to add sound from the iMovie sound effects library; under sandboxing this is not possible since it is not allowed. I allow users to drag in folders and add several photos at once. This is no longer possible with security scoping since the user needs to explicitly authorize each file. They can still use the open dialog to do this; but that's a much slower technique. In theory they can drag a group of individual files (as opposed to a folder) from the Finder too, but this functionality (with security scoping) is still broken under 10.8. (Bug reported, no response from Apple, who knows when it will be fixed). When the link to a file becomes broken, I allow the user to find the missing file via a file dialog. When they find the file, I automatically look for other broken links that are in the same directory, saving them the effort of finding them manually. This is no longer possible under sandboxing since the user must explicitly grant permission for each file. I store the links to files using a relative path, if possible. Security scoped files don't support this. So if the user renames the enclosing folder, all links to the files are broken. > (I mean, you *are* aware that Apple offers an API for exactly that > use-case, where you need to also read those "side-by-side" files of a > given document? Oh and yes: Probably "runs on Lion and above only") To support sandboxing I have to instead store the associated security context object in addition to the URL. This requires considerable work on my part to update my software. The security context is embedded into an NSObject and can only be serialized by serializing the NSObject. So now my model code has to keep an NSObject to keep a pointer to a file. And when it wants to serialize it to a file, it needs to use Cocoa to do the encoding and un-encoding. My documents are currently portable (yeah Qt!) between Windows and Mac. I store relative paths to the files if possible. So if I want to keep them portable (at least in the case where the user copies files into their sandbox), I still have to save out a filename and support that code too. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
