[Interest] Qt 5 and Mac App Store

[Till Oliver Knoll]

Am 19.10.2012 um 18:46 schrieb Chris Meyer <cmeyer1969+qt at gmail.com>:

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

So okay, I understand we are now talking about a whole bunch of *different* use cases than just "document-scoped bookmarks".

Possible that you cannot reference files with any possible means. I think what you are referring to is a "logical folder" rather than a physical one and that this folder is not presented in the powerboxed file dialog? I guess the user could always navigate to the "physical folder" where the effects are stored. Except off course that that folder is probably located inside the iMovie resources bundle and hence not accessible via an ordinary file dialog.

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

Uh, that is in contrast to what I think the official Apple docs state: they mention exactly the example of the user dragging the ~/Documents folder onto the application, and the app should then have access to any file and subfolder therein!


> They can still use the open dialog to
> do this; but that's a much slower technique.

Agreed :) Maybe that is simply a bug then, too, that you cannot specify folders and get full access to the files therein...

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

Well, a bug then - but at least should work "by design" ;)

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

Again, that should work if you let the user locate the file by letting the user specify the folder (instead of the new path to the missing file itself). Then if my above understanding of the Apple docs is correct then you should be able to also open files in that same folder (and subfolders).


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

That is clearly a pain. But I am pretty sure that this is such a huge pain that Apple needs to think that one over! I mean it would not just be renaming the containing folder, but simply moving the document (the containing folder) somewhere else - and bang! you could not open that document (the referenced files) anymore?


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

Yes. But that does not affect "usability" - that just means more work for us developers ;)

Cheers,
  Oliver