Populating NSPopupButton from Core Data array controllers in view-based NSTableViews
I am using view-based NSTableView that is populated using bindings and array controllers with core data. Everything works as advertised by Apple--cells with text and buttons and cells with image and text--I can edit the text as well, etc. Awesome! However, what I can't figure out (have researched and read the manual) is how to populate the popup button menu. There are 2 array controllers in the NIB with data coming from Core Data, one for table view and one for popup buttons menu items. I have tried binding the popup menu the classic way: by binding content (arrangedObjects to entity Place), content values (arrangedObjects Place.name), and selected object (Table Cell View objectValue.places.name. Shouldn't all the controls should work like normal controls in view based tableviews? The menu is not getting populated, I get the Item 1, Item 2, Item 3 menu items. However, if the tableView's entity already has a value/relation set the value is being shown correctly. Any help would be super. Thanks, Dan ___ 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
Dumb Q about console I/O under ObjC
I'm trying to develop my retro CRPG game engine as a console app, but how do I test the input part? I can output to stdio with either printf() or NSLog, but the debug console only supports output, not input. What's the normal way to redirect this to terminal.app so that scanf() will work? ___ 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: Dumb Q about console I/O under ObjC
On 27 May 2012, at 18:26, William Squires wrote: I'm trying to develop my retro CRPG game engine as a console app, but how do I test the input part? I can output to stdio with either printf() or NSLog, but the debug console only supports output, not input. What's the normal way to redirect this to terminal.app so that scanf() will work? Since when does the debugger console only support output? Bob ___ 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
UIDocument and non-thread-safe Model
Hi, when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe. If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call? Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ... The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the document (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the in-memory model must also be serialized. Or did I miss something? Regards, Mani ___ 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: UIDocument and non-thread-safe Model
The general idea is that you make some kind of copy of your model's state and pass that as the document's content, leaving the background free to write it at its leisure. On 27 May 2012, at 21:35, Manfred Schwind wrote: Hi, when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe. If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call? Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ... The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the document (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the in-memory model must also be serialized. Or did I miss something? Regards, Mani ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: UIDocument and non-thread-safe Model
Yes, in the simple case, you as the client only implement contentsForType: and loadFromContents:error:, which are both main thread hooks and you never need to worry about threading. You, the original poster, are correct in your observation that there is no support for a synchronous saving model. This is by design. Applications are encouraged to support iCloud storage, and in an iCloud world, reads and writes can block for indeterminate amounts of time. So, we don't want to encourage anyone to build I/O into the main thread. Luke On May 27, 2012, at 3:50 PM, Mike Abdullah cocoa...@mikeabdullah.netmailto:cocoa...@mikeabdullah.net wrote: The general idea is that you make some kind of copy of your model's state and pass that as the document's content, leaving the background free to write it at its leisure. On 27 May 2012, at 21:35, Manfred Schwind wrote: Hi, when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe. If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call? Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ... The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the document (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the in-memory model must also be serialized. Or did I miss something? Regards, Mani ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.netmailto:cocoa...@mikeabdullah.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com This email sent to luket...@apple.commailto:luket...@apple.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: UIDocument and non-thread-safe Model
Interesting. When exactly should the copy be made? When subclassing UIDocument the usual methods (writeContents:... or similar) are already called on the separate thread. Can I dispatch making the copy on the main thread with dispatch_sync(dispatch_get_main_queue(), ...) ? Is that anywhere discussed in the documentation? Mani Am 27.05.2012 um 22:49 schrieb Mike Abdullah: The general idea is that you make some kind of copy of your model's state and pass that as the document's content, leaving the background free to write it at its leisure. On 27 May 2012, at 21:35, Manfred Schwind wrote: Hi, when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe. If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call? Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ... The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the document (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the in-memory model must also be serialized. Or did I miss something? Regards, Mani ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: UIDocument and non-thread-safe Model
You want to override contentsForType:. That is the main thread hook. This is discussed in http://developer.apple.com/library/ios/DOCUMENTATION/DataManagement/Conceptual/DocumentBasedAppPGiOS/Introduction/Introduction.html Luke On May 27, 2012, at 4:15 PM, Manfred Schwind li...@mani.demailto:li...@mani.de wrote: Interesting. When exactly should the copy be made? When subclassing UIDocument the usual methods (writeContents:... or similar) are already called on the separate thread. Can I dispatch making the copy on the main thread with dispatch_sync(dispatch_get_main_queue(), ...) ? Is that anywhere discussed in the documentation? Mani Am 27.05.2012 um 22:49 schrieb Mike Abdullah: The general idea is that you make some kind of copy of your model's state and pass that as the document's content, leaving the background free to write it at its leisure. On 27 May 2012, at 21:35, Manfred Schwind wrote: Hi, when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe. If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call? Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ... The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the document (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the in-memory model must also be serialized. Or did I miss something? Regards, Mani ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.netmailto:cocoa...@mikeabdullah.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com This email sent to luket...@apple.commailto:luket...@apple.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
Animating source view design advice.
Hi, I would like to create a source view like Xcode 4's project navigator view. It will have parent views (e.g. the project) with a twist down triangle that, when clicked, will reveal the contents (e.g. files) in an animation that slides down. Many of these parent views can exist at the top level. When one is revealed, the ones below will slide down as well. What is the best way to implement this? Is a table view with NSTableCellView's a reasonable approach? I'm wondering if that is the case since the items (when opened) will easily have differing heights depending on the number of children. Is an NSOutlineView more appropriate here (at least I get the sliding animation for free). One complication is that I'd like to be able to select the parent view in the same way that you can in Xcode (that brings up the project/targets inspector) to bring up a summary detail view. I don't need a full implementation (not that I'd turn it away if one is available!), but a high-level view of the best approach to do this would be greatly appreciated! Cheers, Demitri ___ 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
IKImageBrowser crash
Hi all, I'm trying to track down a very bad hard crash when using
IKImageBrowserView.
I'm using this pretty much in its standard form - I don't subclass anything, I
just have a window with an IKImageBrowserView in it, and supply it through its
normal dataSource and delegate protocols.
Previously, the image data type passed back was
IKImageBrowserPathRepresentationType, but as we're adding SVG support to the
app, we changed this for IKImageBrowserQuickLookPathRepresentationType which
uses QuickLook to preview SVG files (as well as all the usual image types).
This appears to work fine with no loss of functionality over the previous image
type, and of course adds SVG.
// view's datasource:
- (NSString*) imageRepresentationType
{
return IKImageBrowserQuickLookPathRepresentationType;
}
At some point we started to encounter a repeatable crash with a folder full of
SVG files. On the assumption it was one particular file, we've been trying to
identify which file it was, but could not. After some time we started to
realise it wasn't a particular file but the number of files we were trying to
preview - it seems as though once some number is exceeded (still trying to
narrow down at what point that occurs), IKImageBrowserView crashes very badly
indeed:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Application Specific Information:
objc[350]: garbage collection is OFF
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7fff8ef55ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x7fff8b91d7d2 pthread_kill + 95
2 libsystem_c.dylib 0x7fff8b90ea7a abort + 143
3 libGLProgrammability.dylib 0x000108b944b9
__reloadBuiltInScopes_block_invoke_1 + 179
4 libdispatch.dylib 0x7fff8542a3f0 dispatch_once_f + 53
5 libGLProgrammability.dylib 0x000108b93e81 nameTableGet + 92
6 libGLProgrammability.dylib 0x000108b93dfb
glpNameTableGetVariableLikeObject + 35
7 libGLProgrammability.dylib 0x000108b92bc3
glpSAVariableDeclaration + 283
8 libGLProgrammability.dylib 0x000108b8f81a glpSANode + 10534
9 libGLProgrammability.dylib 0x000108b8f8a0 glpSANode + 10668
10 libGLProgrammability.dylib 0x000108b917da glpSANode + 18662
11 libGLProgrammability.dylib 0x000108b7a6be glpCompileShader +
176
12 libGLProgrammability.dylib 0x000108b79ca5 ShCompile + 218
13 GLEngine0x000108ab8c07 gleShaderParse + 221
14 GLEngine0x000108a14cf8
glCompileShaderARB_Exec + 230
15 com.apple.imageKit 0x7fff8654d78d IKLoadShader + 348
16 com.apple.imageKit 0x7fff865fae6f
-[IKGLTextSubpixelShader initWithFragmentCode:] + 130
17 com.apple.imageKit 0x7fff865fbc4d -[IKGLTextRenderer
flush] + 222
18 com.apple.imageKit 0x7fff86556f1d
-[IKImageBrowserView(ImageBrowserDrawing) drawWithCurrentRendererInRect:] + 349
19 com.apple.imageKit 0x7fff86557c8b
-[IKImageBrowserView(ImageBrowserDrawing) drawRect:] + 728
20 com.apple.AppKit0x00010043497a -[NSView
_drawRect:clip:] + 3758
21 com.apple.AppKit0x000100461b4f -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1583
This is the relevant part - the bottom of the stack trace is just the standard
[NSView displayIfNeeded] call to redraw the window.
This is on a dual-GPU MacBook Pro, which might be taking a different pathway
than another machine because of the internals of compiling OpenGL code (I
think, I'm not much of an expert on this stuff).
The question is, what, if anything, can we do to help ourselves out of this
problem? To answer this we need to know what the problem is - is it running out
of memory on the GPU? Is it trying to process bad data and getting stuck? The
difficulty for us is that because we're not doing anything beyond ImageKit's
own classes, there's very few places we can step in to fix things. At a pinch
we can limit the number of files displayed per folder, but that seems a bit
kludgey.
Any insights?
--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
Losing memory
My application is using (leaking) too much memory and eventually dies because no more can be allocated. I have used Instruments to measure the usage and leaks and have addressed those it told me about. Now, however, Instruments indicates that memory reaches a steady state (no more increases) yet the app continues to die for lack of memory. Does anyone know of a next step I can take to help track down this problem? Charlie Dickman 3tothe...@comcast.net ___ 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
Sandboxing. WTF?
OK, none of us want it, it doesn't solve an actual problem, and it barely works. But we have to do it anyway. I turned on Sandboxing in my project and now I cannot run my app at all. This is logged: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? --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: Sandboxing. WTF?
On 27 May 2012, at 9:19 PM, Graham Cox wrote: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? Examine your entitlements file. If the entry the Gateway daemon complains of (com.apple.developer.ubiquity-container-identifiers) is there, delete it. I assume you aren't supporting iCloud. — F -- Fritz Anderson Xcode 4 Unleashed, making life worth living. http://x4u.manoverboard.org/ ___ 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: Sandboxing. WTF?
On May 27, 2012, at 10:19 PM, Graham Cox graham@bigpond.com wrote: I turned on Sandboxing in my project and now I cannot run my app at all. This is logged: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, You're using iCloud (which requires sandboxing) but the system can't verify your app's signature. how do I fix it Ensure your app is signed correctly and the correct provisioning profile is installed not only in Xcode but *also* in the Profiles System Preferences pane. This preference pane will not appear until the first profile is installed. To install profiles in System Preferences, double-click the profile in Finder, you can right-click the profile in the Xcode organizer to Reveal the profile in Finder. and how do I go about testing a sandboxed app during development? Once you get provisioning straightened out, debugging g and testing should be as normal. You need to make sure all testing machines are correctly provisioned as well, which means you are limited to a certain number of testing devices (100?). --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: Sandboxing. WTF?
On 28/05/2012, at 12:28 PM, Fritz Anderson wrote: On 27 May 2012, at 9:19 PM, Graham Cox wrote: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? Examine your entitlements file. If the entry the Gateway daemon complains of (com.apple.developer.ubiquity-container-identifiers) is there, delete it. I assume you aren't supporting iCloud. Ah, got it, thanks Fritz. I'm not using iCloud. In fact I was able to simply remove the iCloud Key-Value Store and iCloud Containers in the Entitlements UI in XCode and it's running. Sort of related question to the floor: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. If not, words fail me.. --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: Bug in 10.6 NSPasteboard API? (was: Sending a list of path strings to the Finder via Scripting Bridge)
On May 26, 2012, at 4:41 AM, Peter wrote: thank you very much for your enlightening and in-depth explanation! You're welcome. With the old API I could (and still do) put a list of path strings with empty elements on the pasteboard, e.g. four paths, the third one empty as in /path1/item1 /path2/item1 /path2/item2 but since the new API moved to NSURLs I don't see a way to accomplish this. I could not find something like an empty NSURL. I use this for copying data from a table area to another table or table area, meaning the empty element is a valid piece of data. Any ideas? I'm not certain. You can try putting an NSPasteboardItem to which you haven't added any data in the list of items. You can try adding some other type of data, perhaps a custom type which indicates to your app that there's no data. You can put a different kind of NSURL, rather than a file URL, perhaps with a custom scheme meaningful only to your app. Etc. The main thing is to think of the pasteboard contents as multiple items, each with its own types/representations, which can be (but doesn't have to be) different from all of the other items. Regards, Ken ___ 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: Sandboxing. WTF?
On May 27, 2012, at 19:44 , Graham Cox wrote: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. AFAIK, the (a?) correct procedure is to ask the user to locate the items you want to reference, using the standard Open dialog. (This gives the user a chance to opt out.) From the result, you'll need to create a sandbox-bridging bookmark to the relevant authenticated URL, and store the bookmark in your own sandbox. Then, in future invocations of your app, you should be able to resolve the bookmark silently. The only fly in the ointment here is that the special bookmark requires a recent version of OS X. (I can't remember which one, perhaps it was 10.7.3.) On older versions, your only options would be to (a) withdraw the feature, or (b) ask the user the first time the reference is needed in each app invocation. (Well, the in the case of grabbing resources, you might be able to keep the resources themselves in your sandbox, and not have to go back to the source again.) If not, words fail me.. Well, I understand the frustration, but you *have* been getting somewhat of a free ride. You have (in effect, like a lot of us) been poking around in the user's file system and grabbing whatever you want. There's no *essential* difference between that and malware. That last statement has very sharp corners and is hard to swallow, but it seems inescapable if we are to have our security be actually, you know, secure. ___ 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
NSXMLParser and initWithStream
I'm trying to use the NSStream classes to parse incoming incremental XML data.
The data is never a complete XML Document, but I want to receive and process it
in incremental chunks based off how much ever the socket can read.
Looking at the documentation for NSXMLParser, it seems like the initWithStream:
method to initialize a NSXMLParser would be the perfect solution to my problem.
I can initialize the parser with a NSInputStream and then call the parse method
on NSXMLParser whenever I receive data over my socket which should in turn call
the NSXMLParser delegates.
However, I'm not seeing any of the delegates being called, the only method I
see being called is the stream delegate stream:handleEvent:. There seems to be
little to no examples of this API from Apple or other developers. I could use
libxml2 directly to accomplish what I want, but I am hoping I am just using
NSXMLParser incorrectly.
Here is the source for what I am trying:
ContentParser.h:
@interface ContentParser : NSObject NSStreamDelegate,
NSXMLParserDelegate
{
NSInputStream *inputStream;
NSOutputStream *outputStream;
NSMutableData *receivedData;
NSXMLParser *xmlParser;
}
- (void)initStream;
ContentParser.m:
@implementation ContentParser
- (void)initStream
{
CFReadStreamRef readStream;
CFWriteStreamRef writeStream;
CFStreamCreatePairWithSocketToHost(kCFAllocatorDefault,
(CFStringRef)@hostname,
port,
readStream,
writeStream);
inputStream = (__bridge NSInputStream *)readStream;
outputStream = (__bridge NSOutputStream *)writeStream;
inputStream.delegate = self;
outputStream.delegate = self;
[inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop]
forMode:NSDefaultRunLoopMode];
[outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop]
forMode:NSDefaultRunLoopMode];
[inputStream open];
[outputStream open];
xmlParser = [[NSXMLParser alloc] initWithStream:inputStream];
[xmlParser setDelegate:self];
}
- (void)parser:(NSXMLParser *)parser didStartElement:(NSString
*)elementName
namespaceURI:(NSString
*)namespaceURI
qualifiedName:(NSString *)qName
attributes:(NSDictionary
*)attributeDict
{
NSLog(@didStartElement: %@, attributeDict: %@, elementName,
attributeDict);
}
- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
{
NSLog(@foundCharacters: %@, string);
}
- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName
namespaceURI:(NSString *)namespaceURI
qualifiedName:(NSString *)qName
{
NSLog(@didEndElement: %@, elementName);
}
- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError
*)parseError
{
NSLog(@Error %ld, Description: %@, Line: %ld, Column: %ld,
[parseError code], [[parser parserError] localizedDescription],
[parser lineNumber], [parser columnNumber]);
}
- (void)stream:(NSStream *)stream handleEvent:(NSStreamEvent)eventCode
{
switch (eventCode) {
case NSStreamEventHasBytesAvailable:
{
if (stream == inputStream) {
NSInputStream *is = (NSInputStream *)stream;
if (receivedData == nil) {
receivedData = [[NSMutableData alloc] init];
}
uint8_t buf[1024];
NSInteger bytesRead = [is read:buf maxLength:1024];
if (bytesRead == -1) {
NSLog(@Network read error);
} else if (bytesRead == 0) {
NSLog(@No buffer received);
} else {
[receivedData appendBytes:buf length:bytesRead];
BOOL parserResult = [xmlParser parse];
if (parserResult == NO) {
NSLog(@Unable to parse XML);
}
}
}
break;
}
default:
break;
}
}
@end
___
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:
Re: Sandboxing. WTF?
On 28/05/2012, at 1:42 PM, Quincey Morris wrote: On May 27, 2012, at 19:44 , Graham Cox wrote: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. AFAIK, the (a?) correct procedure is to ask the user to locate the items you want to reference, using the standard Open dialog. (This gives the user a chance to opt out.) From the result, you'll need to create a sandbox-bridging bookmark to the relevant authenticated URL, and store the bookmark in your own sandbox. Then, in future invocations of your app, you should be able to resolve the bookmark silently. The only fly in the ointment here is that the special bookmark requires a recent version of OS X. (I can't remember which one, perhaps it was 10.7.3.) On older versions, your only options would be to (a) withdraw the feature, or (b) ask the user the first time the reference is needed in each app invocation. (Well, the in the case of grabbing resources, you might be able to keep the resources themselves in your sandbox, and not have to go back to the source again.) OK, I've found some discussions and info elsewhere along these lines which gives me something to work on. I'm not against asking the user for permission to do this, as long as it doesn't become too intrusive. Currently though, my implementation falls at the first hurdle, which is here: CFArrayRef recentLibraries = CFPreferencesCopyAppValue((CFStringRef)@iPhotoRecentDatabases,(CFStringRef)@com.apple.iApps); This returns nil in the sandboxed version, even though I have added /Library/Preferences/com.apple.iApps.plist to my temporary exception entitlements (user relative, read only). Oddly, I do not get a sandboxd deny logged, which is why I was assuming it wasn't working at first. It must be something else, but it works just fine in the non-sandboxed app. Anyone else run into this? If not, words fail me.. Well, I understand the frustration, but you *have* been getting somewhat of a free ride. You have (in effect, like a lot of us) been poking around in the user's file system and grabbing whatever you want. There's no *essential* difference between that and malware. That last statement has very sharp corners and is hard to swallow, but it seems inescapable if we are to have our security be actually, you know, secure. Well, perhaps. But it's not really developers getting a free ride as much as users getting used to a nice feature that makes their apps easier to use. I'm far from the only app doing this, many do, and many integrate the entire iMedia browser to do it as well. I guess what pains me is that Apple have not as yet provided a sanctioned way to implement this feature. Maybe they will in future and I certainly hope so, but what's nasty about the current situation is that they have not made an officially sanctioned API available BEFORE imposing the sandboxing requirement on app developers. To me, that's pretty heavy-handed behaviour. I could understand it to a degree if there was a major issue right now with malware using this sort of thing to do its dirty work that needed to be shut down urgently, but AFAICS, it's a non-issue in practice. --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: Sandboxing. WTF?
On May 27, 2012, at 9:55 PM, Graham Cox wrote: Currently though, my implementation falls at the first hurdle, which is here: CFArrayRef recentLibraries = CFPreferencesCopyAppValue((CFStringRef)@iPhotoRecentDatabases,(CFStringRef)@com.apple.iApps); This returns nil in the sandboxed version, even though I have added /Library/Preferences/com.apple.iApps.plist to my temporary exception entitlements (user relative, read only). Oddly, I do not get a sandboxd deny logged, which is why I was assuming it wasn't working at first. It must be something else, but it works just fine in the non-sandboxed app. Anyone else run into this? AppSandboxDesignGuide.pdf says: == Accessing Preferences of Other Apps Because App Sandbox directs path-finding APIs to the container for your app, reading or writing to the user’s preferences takes place within the container. Preferences for other sandboxed apps are inaccessible. Preferences for apps that are not sandboxed are placed in the ~/Library/Preferences directory, which is also inaccessible to your sandboxed app. If your app requires access to another app’s preferences in order to function—for example, if it requires access to the playlists that a user has defined for iTunes—let Apple know about your needs using the Apple bug re- porting system. In addition, be sure to follow the guidance regarding entitlements provided on the iTunes Connect website. With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. A POSIX function, such as getpwuid, can provide the file system path you need. For details on entitlements, see Entitlement Key Reference . I think that is your issue. ___ 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: Sandboxing. WTF?
On 28/05/2012, at 3:10 PM, Marco S Hyman wrote: I think that is your issue. What is the issue? I have read that, several times. It states: With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. Well, that's what I am doing as I pointed out in my last message. But I still am unable to read the particular pref I need. (I have filed a radar asking that this feature be made available officially as well, but it's certainly a dupe). --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: Sandboxing. WTF?
On May 27, 2012, at 21:55 , Graham Cox wrote: users getting used to a nice feature that makes their apps easier to use Of course, but that's one of sharp, hard-to-swallow corners. Insecure is insecure. I guess what pains me is that Apple have not as yet provided a sanctioned way to implement this feature. AFAIK, you can still submit an un-sandboxed app and *request* an exemption until Apple provides an appropriate entitlement. Perhaps you might get it. Perhaps the need to access the iPhoto library might fall into this category. Perhaps Apple might ask if you submitted a bug report asking for a new kind of entitlement for your situation, sometime in the year or so since the sandboxing requirement was first announced. :) (I don't think the sandbox-aware bookmark thing was available till long after the original must-enable-sandboxing deadline of Nov 2011. I'm guessing it was only conceived after a bunch of complaints.) I could understand it to a degree if there was a major issue right now with malware using this sort of thing to do its dirty work that needed to be shut down urgently, but AFAICS, it's a non-issue in practice. You mean like uploading the user's entire iOS contacts DB to a developer's own server? Or storing the user's cell tower connection history in a file? Those made apps easier to use. Made lawyers richer, too. P.S. I'm not picking on your specifically. Call me a glass-quarter-full kind of person, but I think we (developers in general, over the past 50 years, not Mac developers specifically) have proved *repeatedly* that we can't be trusted to put user convenience first without creating truck-sized security holes. FWIW. ___ 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: Sandboxing. WTF?
On 28/05/2012, at 3:23 PM, Quincey Morris wrote: You mean like uploading the user's entire iOS contacts DB to a developer's own server? Or storing the user's cell tower connection history in a file? Those made apps easier to use. Made lawyers richer, too. Well, those things happened on an OS that has had sandboxing from day one. It didn't stop it, did it? People will always click Allow if it gives them an easy life. --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
