NSUserUnixTask and the sandbox
Has anyone much experience with NSUserUnixTask to run scripts outside of the sandbox? Can one, for instance, use the script to execute a helper auxiliary from the app bundle that would have been sand boxed if executed directly via NSTask? Regards Jonathan Mitchell Mugginsoft LLP ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserUnixTask and the sandbox
To get outside the sandbox, the scripts have to be placed (by the end user) in a special scripts folder which sandboxed apps can read from, but cannot write to. It will (should) fail if you try to create a script task from a URL that isn't inside the special folder. Apple specifically says you cannot use NSUserScriptTask for scripts inside your bundle and need to stick with NSTask. Session 206 from the WWDC 2012 videos covers this in much better detail. Mark On Fri, Nov 30, 2012 at 12:10 AM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: Has anyone much experience with NSUserUnixTask to run scripts outside of the sandbox? Can one, for instance, use the script to execute a helper auxiliary from the app bundle that would have been sand boxed if executed directly via NSTask? Regards Jonathan Mitchell Mugginsoft LLP ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com This email sent to unmar...@gmail.com -- Mark Munz unmarked software http://www.unmarked.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserUnixTask and the sandbox
On 30 Nov 2012, at 08:39, Mark Munz unmar...@gmail.com wrote: To get outside the sandbox, the scripts have to be placed (by the end user) in a special scripts folder which sandboxed apps can read from, but cannot write to. It will (should) fail if you try to create a script task from a URL that isn't inside the special folder. Apple specifically says you cannot use NSUserScriptTask for scripts inside your bundle and need to stick with NSTask. Session 206 from the WWDC 2012 videos covers this in much better detail. Thanks Mark. I will check out the session. Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Checking if mouse event was generated by touch
Hi Kyle, The subtype for the mouse event comes to be NSMouseEventSubtype(same as that for a normal mouse event). The mouse events for the pen have the subtype of NSTabletPointEventSubtype, but not touch. On Wed, Nov 28, 2012 at 10:09 PM, Kyle Sluder k...@ksluder.com wrote: On Nov 28, 2012, at 7:35 AM, Akhil Jindal akhi...@gmail.com wrote: I want to check whether the mouse event received was generated through an actual mouse, or through a touch(possibly on an external direct touch display attached to the machine(like the Wacom Cintiq)). I can receive the touch events through the Wacom APIs and want to ignore the mouse event generated for the same action, by the OS. See the documentation for -[NSEvent subtype] and NSTabletPointEventSubtype. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On 30 Nov 2012, at 01:16, Sean McBride s...@rogue-research.com wrote: On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said: With all the different features of the document system these days, it can be pretty hard to slot them all in nicely with Core Data. People may find https://github.com/karelia/BSManagedDocument pretty handy for this (the real meat is in the header file at present) Wow, that looks pretty awesome if it does all that is advertised. It's only 700 LOC, which really does make me wonder why NSPersistentDocument can't do all these things. Core Data didn't get any love in 10.8 at all. The conspiracy theorist in me wonders... One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView / NSToolbar drawing woes [SOLVED]
Thank you for your reply. It seems as though when you make a thorough explanation in writing of what your problem is then the right solution is found more easily. :) I struggled with this problem for a week and couldn't, for the life of me, find out what the problem was; that is why I posted my problem here. However, my description led me to comment out all the drawing code and then reinsert this code line by line until I found the line of code that was messing the toolbar up. The offending line of code was an unbalanced call to store the graphics context. Once removed the problem went away. I'm somewhat amazed of how such a small mistake could mess up the toolbar drawing so much. On 30/11/12 05:20, Graham Cox graham@bigpond.com wrote: When your custom view is activated, it should be made first responder, which is responsible for validating the toolbar - check out NSUserInterfaceValidation. Your -drawRect: does not need to account for the toolbar (but it also should take some care not to mess up the graphics environment, though that is hard to do - I doubt that's the problem) --Graham On 30/11/2012, at 2:32 PM, João Varela joaocvar...@gmail.com wrote: ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSApplicationScriptsDirectory access for helper tool
In a sandboxed app I do the following for say com.mystuff.app and a folder named com.mystuff.app is created in NSApplicationScriptsDirectory as expected. NSError *error = nil; NSURL *scriptsFolderURL = [[NSFileManager defaultManager] URLForDirectory:NSApplicationScriptsDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:error]; MLogInfo(@NSApplicationScriptsDirectory = %@, scriptsFolderURL); Now I also have a helper app identified as com.mystuff.app-helper. Trying to access url for the NSApplicationScriptsDirectory from within the helper yields an error saying that I don't have permission to save com.mystuff.app-helper into NSApplicationScriptsDirectory. Is this as expected and is there a workaround? Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSApplicationScriptsDirectory access for helper tool
I think that this question can be distilled down to : Can a sandboxed app bundle helper tool use NSUserUnixTask to run a user script in NSApplicationScriptsDirectory? All my attempts have failed. Regards Jonathan Mitchell On 30 Nov 2012, at 13:50, jonat...@mugginsoft.com wrote: In a sandboxed app I do the following for say com.mystuff.app and a folder named com.mystuff.app is created in NSApplicationScriptsDirectory as expected. NSError *error = nil; NSURL *scriptsFolderURL = [[NSFileManager defaultManager] URLForDirectory:NSApplicationScriptsDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:error]; MLogInfo(@NSApplicationScriptsDirectory = %@, scriptsFolderURL); Now I also have a helper app identified as com.mystuff.app-helper. Trying to access url for the NSApplicationScriptsDirectory from within the helper yields an error saying that I don't have permission to save com.mystuff.app-helper into NSApplicationScriptsDirectory. Is this as expected and is there a workaround? Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/jonathan%40mugginsoft.com This email sent to jonat...@mugginsoft.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSPointerArray on iOS - truly __weak?
The docs for NSPointerArray say, in a big bold box right at the top: Important: NSPointerArray does not support weak references under Automatic Reference Counting (ARC). However, a [NSPointerArray weakObjectsPointerArray] does NULL an element that has been released through ARC; I can test this directly, and I've also been using NSPointerArray successfully to break retain cycles. So are the docs just lying (in a big bold box right at the top), or is this some other kind of weak reference (i.e. somehow weak, but not ARC-__weak)? m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On 2012-11-30, at 6:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 30 Nov 2012, at 01:16, Sean McBride s...@rogue-research.com wrote: On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said: With all the different features of the document system these days, it can be pretty hard to slot them all in nicely with Core Data. People may find https://github.com/karelia/BSManagedDocument pretty handy for this (the real meat is in the header file at present) Wow, that looks pretty awesome if it does all that is advertised. It's only 700 LOC, which really does make me wonder why NSPersistentDocument can't do all these things. Core Data didn't get any love in 10.8 at all. The conspiracy theorist in me wonders... One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On 30 Nov 2012, at 18:59, Dave Fernandes dave.fernan...@utoronto.ca wrote: On 2012-11-30, at 6:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context - works entirely on the main thread - only ever saves on top of itself, or to a new location using Save As I wonder if there's simply too much fragility in the existing subclasses that people have shipped, which make it a royal pain to try and modernise. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On Fri, 30 Nov 2012 21:46:24 +, Mike Abdullah said: Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context - works entirely on the main thread - only ever saves on top of itself, or to a new location using Save As I wonder if there's simply too much fragility in the existing subclasses that people have shipped, which make it a royal pain to try and modernise. Could be. But Apple could have provided a NSPersistentDocument2 class that people could opt into. But they haven't. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On 01/12/2012, at 9:01 AM, Sean McBride s...@rogue-research.com wrote: Could be. But Apple could have provided a NSPersistentDocument2 class that people could opt into. But they haven't. Have you noticed that they never do this though? It must be some sort of policy because there are numerous examples where a fork would seem to make more sense than adding more and more features to a class. NSTableView comes to mind among others. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On Sat, 1 Dec 2012 09:49:23 +1100, Graham Cox said: Could be. But Apple could have provided a NSPersistentDocument2 class that people could opt into. But they haven't. Have you noticed that they never do this though? It must be some sort of policy because there are numerous examples where a fork would seem to make more sense than adding more and more features to a class. NSTableView comes to mind among others. Sorta... I mean, they'd never use a stupid name like NSPersistentDocument2. But it's not so different from entirely deprecating NSMovieView and calling it QTMovieView. They sometimes do something else, like a big fat mode switch like NSDateFormatterBehavior10_4. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: FileWrapper iCloud
On 2012-11-30, at 4:46 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 30 Nov 2012, at 18:59, Dave Fernandes dave.fernan...@utoronto.ca wrote: On 2012-11-30, at 6:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context This definitely limits your options. But, is it necessary to support file wrappers and iCloud? (Just trying to educate myself about how documents work.) - works entirely on the main thread This one is already opt-in for both opening and saving, so fragility shouldn't be an issue to upgrading the class. [Aside: As far as I know you *can* actually open an NSPersistentDocument asynchronously. At least I haven't seen anything that says you can't, and it seems to work on every system I've tried it on.] - only ever saves on top of itself, or to a new location using Save As I guess this is an implementation detail to me. I want to manage the data model and let the framework classes handle the document stuff. If they could add all the Lion document behaviors to NSPersistentDocument, I don't see how they couldn't add file wrapper support. But then, I've never tried. (I have filed plenty of bug reports though. :) I wonder if there's simply too much fragility in the existing subclasses that people have shipped, which make it a royal pain to try and modernise. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
