Am 19.10.2012 um 18:46 schrieb 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
Am 19.10.2012 um 18:20 schrieb Daniel Price :
>
>> Ah, okay then, but still: if your application *wanted* to be malicious and,
>> say, delete the file the user has such selected via file dialog, ...
>
> Hmm I'm pretty sure that sandboxing is there to prevent *you* from doing
> thing's not yo
>> 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
>Ah, okay then, but still: if your application *wanted* to be malicious and,
>say, delete the file the user has such selected via file dialog, or maybe even
>at some later point by "security-scoping" that file and only delete it
>"silently" much much later, then the sandbox would not prevent su
2012/10/19 Chris Meyer :
> ...
> My application keeps a main document and a list of linked photos and
> movies that go into the document. The linked files would require me to
> keep around a "security scope" for the files.
I think that is exactly what I meant previously by "document security
scope
2012/10/19 Daniel Price :
>> ...
>> Nothing. Plain and simple. (I am not sure to what APIs you are actually
>> referring to, but let's just assume they existed).
>
> I was referring to the security-scoped URLs.
Ah, okay then, but still: if your application *wanted* to be malicious
and, say, delet
> However I wouldn't know why you wanted to "security-scope" a given
> file if the intention was *not* to place it into the Recent Files
> menu, too - I currently just don't see any other use case than the
> "Recent Files". So why not come up with a QRecentFileMenu (which would
> be a welcomed clas
> (I for my part have still Snow Leopard on my work iMac - Mountain Lion is
> just for toying around on the MacBook Pro. However to be fair Apple corrected
> many issues they completely did wrong in their "Vista"
release of Lion: it is almost as good as Snow Leopard again ;) But I am getting
OT
2012/10/19 Daniel Price :
> I looked into Security Scoped URLs when I was trying to a Qt app in the MAS a
> few months back (which is why I brought it up).
>
> These APIs (or rather the ones relevant to sandboxing - file URLs have been
> around on OSX for years) were only added in the very last v
lto:interest-bounces+daniel.price=fxhome@qt-project.org] On Behalf Of
Till Oliver Knoll
Sent: 19 October 2012 10:55
To: Qt Interest
Subject: Re: [Interest] Qt 5 and Mac App Store
2012/10/19 Daniel Price :
> What's the solution to the file-link issue in Qt? Sandboxing prevents an app
2012/10/19 Daniel Price :
> What's the solution to the file-link issue in Qt? Sandboxing prevents an app
> from reading or writing to any file other than those chosen specifically by a
> user via powerbox (the native dialogs). So if you app has a 'recent file'
> list or some other way to access
asi
Sent: 19 October 2012 08:59
To: interest@qt-project.org
Subject: [Interest] Qt 5 and Mac App Store
Hi,
I had a look at the status of Qt 5 on OS X regarding issues with Mac App Store
that were encountered in 4.8. It's looking quite good generally.
File dialog crashes inside a sandbox hav
Hi,
I had a look at the status of Qt 5 on OS X regarding issues with Mac App
Store that were encountered in 4.8. It's looking quite good generally.
File dialog crashes inside a sandbox have been fixed with a patch similar
to the 4.8 one, so Qt 5 apps can run inside a sandbox without issues. Of
co
13 matches
Mail list logo
