[Interest] Qt 5 and Mac App Store

[Chris Meyer]

>>  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.