Re: Sandboxing not so bad
Re: Sandboxing not so bad
- Subject: Re: Sandboxing not so bad
- From: koko <email@hidden>
- Date: Sat, 15 Sep 2012 15:55:19 -0600
Yes, a piece of cake for a piece of cake app.
Try doing something like iterating the file system so you can present to the user all files of unique types you understand that can be anywhere on the system.
The sandbox is like a cat box … to be avoided at all costs.
-koko
On Sep 15, 2012, at 3:01 PM, James Merkel wrote:
>
> On Sep 13, 2012, at 12:45 PM, James Merkel <email@hidden> wrote:
>
>> Sandboxing is not as restrictive than I though it would be.
>>
>> For example, the documentation for the entitlement: com.apple.security.files.user-selected.read-write says this entitlement provides: "Read/write access to files the user has selected using an Open or Save dialog" .
>> I was reading more into that than I should have. If you use the Open dialog to access a file, then you can read and write to the file. You don't have to use the Save dialog to write to the file. And that file
>> can be anywhere on the file system (except for system files I guess).
>>
>> And yes the app is really sandboxed. If no entitlements are enabled I can't do anything (except read and write to recent documents in the Open Recent menu).
>>
>> So with just that entitlement and a Printing Entitlement I can do just about everything I could previously do before Sandboxing.
>> The only thing I can't do is write comments to the Finder GetInfo window -- because that uses Applescript. But I can live without that.
>>
>> So unless I'm missing something, sandboxing is a piece of cake.
>>
>> Thanks,
>>
>> Jim Merkel
>>
>
> Just noticed -- perviously I had the capability to make a change to all files in a folder based on the changes to a particular open file from that folder.
> With Sandboxing, I can't do that anymore since those other files weren't opened from an Open dialog.
> So maybe Sandboxing is not so wonderful.
> On the other hand, one could also say that my previous implementation didn't follow human interface guidelines.
>
> Jim Merkel
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden