On Jan 9, 2015, at 11:05:45, Kyle Sluder <k...@ksluder.com> wrote: > > This sounds basically good. I’d suggest looking into overriding > -[NSWindowController windowDidLoad] rather than using -awakeFromNib.
Good catch. I'm already doing other user defaults loading in windowDidLoad - not sure why I put this one in awakeFromNib. > Conceptually, the stored path is controller-level state, and thus should be > pushed from the controller the view rather than retrieved directly by the > view layer. Since you’re using bindings, you would be well-advised to already > be using a subclass of NSWindowController to manage your window, since that > superclass breaks retain cycles that Cocoa Bindings can cause. This brings up an interesting point, that of where to store data. Since discovering bindings, it seems like one should let the bindings load the data into the view they're bound to. Once the data is there, leave it there and don't make another copy of it, because multiple copies can easily get out of sync. Now since I'm moving this particular piece of data away from bindings, I can see it going either way; add a property to my controller that will own the data and reflect it in the view, or just store it in the view, since it has to be there anyway. Or maybe I should try to read through the bindings docs again, because it seems like there should be a way to bind the NSPathControl's value to my property. I just tried doing that and couldn't make it work by just poking at things. > There is no need to call -startAccessingSecurityScopedResource until you need > to actually read from the file. As long as you have successfully created an > NSURL from the bookmark data, you have access rights to the resource pointed > to by that bookmark. > > As per the documentation, your calls to -start/stopAccessing should be as > tightly scoped as possible, so it would be inadvisable to call > -startAccessing in -awakeFromNib. If NSPathControl needs to read the resource > to determine, say, what icon to provide in a path segment, it will call > -startAccesingSecurityScopedResource on its own. I'm not starting access before the MD query starts, and stopping access when all of my queued operations are done iterating over the results. The problem now is that, while I can access all the files contained within the search dir, the access is stopped before the IKImageBrowserView has had a chance to finish rendering all of the found items, so only a few images show up as the actual image, and the bulk show up as their file icon. And double-clicking an item no longer allows it to be opened with its creator app. Certainly I don't want to attempt to start and stop access for the search dir every time the browser asks for an item's imageRepresentation. I'm guessing I'd run into race states there if multiple items are queried at once. That leaves me with leaving the access open while the app is running, until a new searchDir is chosen. That seems to go against Apple's suggestion. -- Steve Mills Drummer, Mac geek _______________________________________________ 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
