On May 22, 2013, at 5:00 PM, Christopher Nebel wrote: On May 22, 2013, at 11:30 AM, Alex Zavatone < email@hidden> wrote: On May 22, 2013, at 1:45 PM, Christopher Nebel wrote: On May 22, 2013, at 5:10 AM, Shane Stanley <email@hidden> wrote:
On 22/05/2013, at 10:06 PM, Alex Zavatone <email@hidden> wrote:
So, that means that you can't tell an app anything because of Sandboxing, right?
Wrong. It means a sand-boxed app can't send Apple events to another app.
And even that's overstating things -- a sandboxed app can't send Apple events to another app *if it doesn't have entitlements to do so*. The default sandbox doesn't allow sending Apple events to any other app, true, but the default sandbox doesn't allow using the network either, and you don't hear anyone complaining that Apple is deprecating the Internet.
Basically, for 99.9% of apps, this just isn't an issue -- there are mechanisms to let them do what they need. For the 0.1% that do have issues with sandboxing (as currently implemented), it means they can't be in the Mac App Store, but not that they're out of business. And by the way, this was all covered at WWDC 2012, so refer this benighted developer to the "Secure Automation Techniques in OS X" session.
So, yeah, I was being sarcastic in my original reply, but this sandboxing is just onerous and places annoying and expensive implications on the developers. ...
Look, when you're the developer on your own box and you are THE admin, and you're trying to push a multi million dollar product on multiple platforms you DO NOT WANT to have to worry about any of this sandboxing garbage.
PERIOD.
First off, I'm gratified that you used AppleScript and AppleScriptObjC for a project like that. (Can our marketing director quote you? Yes, I'm serious.)
"Hell yes", Alex Zavatone.
AppleScript was the only way I could conceive of actually doing this and I have an amazing case where without this type of solution to allow rapid turnaround, we would have load a lot of money and not been able to ship in time.
But please feel free to tell the team that without their years of hard work and the process automation that AppleScript allowed, there is NO WAY that we would have been able to turn several challenging corners and get dev the content they wanted in the way they wanted it and in a vastly accelerated timeline that allowed us to iterate. UI changes that would take weeks for dev to put in were implemented with a copy and paste of my auto created C and Lua code and then they simply tied their code into their back end.
When a CTO wants a white background and a VP wants a dark blue, we were able to put up both and a third variant since all the manual export of the 100% custom created content was replaced with a click of one button.
And for those who feel the need to hear me talk for 5 minutesÂ…
By the way, I added pList and SVN export to it a few months back. Hope to have the chance to use it in one of my iOS projects soon.
However, to your point: you don't want to deal with sandboxing your projects? Then don't. Really, it's fine. Nothing in Mountain Lion requires that applications be sandboxed. Nothing about your FiOS application would have to change in Mountain Lion. Some of the applications it talks to might be sandboxed, but that doesn't affect their scriptability. Worst case, you might need to sign your application, but that's a no-coding-involved change, and is mostly for convenience.
So, that sandboxing restriction about only being able to save files outside of the supported folders if the user manually OKs a dialog doesn't apply? The restriction about only being able to save to ~/Documents, ~/Music without the user OKing a dialog doesn't apply?
I'm actually going to try and test this, but I don't have AI and PS installed under ML at the moment.
If I can test it, (the app was compiled under Xcode 3.1.3 but I might have a version built under 4.2) I'll let you know. People seem to get this idea that sandboxing is all-pervasive, and it's really not. Being in the Mac App Store requires being sandboxed, because apps there are held to specific standards. Outside of that, though, you're still free to go as nuts as you like.
Well, reading Apple's docs on sandboxing, that's what it says. "Every app is an island" and you can't read/write to files outside the authorized locations. It directly says that user interaction is required to save outside the container directories and the application bundle. Then there is the "can't sell any apps through the App store unless they are sandboxed". And bearing in mind how there is the trend for the Mac OS to get things from iOS, this is the way it is on iOS. In any case, I'm copying over files now and will test. I've just seen too many annoying changes in the Mac OS post Snow Leopard and we either have to hunt for 9 months to turn them off or there is no way to turn off some annoying new behaviour, that this sandboxing looks like more of the same of changes to the root OS that you DO NOT WANT and can not change.
If you know how to disable the stupid animation of content that cascades up and down when you click disclosure triangles in the Finder (or anywhere), you're on my Christmas list. The content display used to be instant. Why must we now sit and watch it animate and we can't turn it off?
It's really annoying when you pay for an OS that you then have to spend so much more of your time trying to get it to be as functional as the system you just left.
In any case, thanks for taking the time to reply. It is appreciated.
--Chris Nebel AppleScript Engineering
|