Re: NSDocument package saving invalidates wrapper? Options?
On 9/1/12 10:23 PM, Mike Abdullah wrote:
It seems you're right; this is a side-effect of how NSDocument does
safe-saving. If the file wrappers internally hold onto the URL they were last
written to, that's no good if the file moves out underneath them. To cope
they'd have to be using a bookmark or file reference URL instead. Apple might
well be doing so in 10.8 or a later OS, but if you need to target 10.7, that
doesn't help!
Thanks for the reply! Not sure I understand, are you saying in 10.8 this problem
is non-existent? I don't see anything in the AppKit release notes indicating a
change of behavior.
I'd make two changes to your routine:
* Instead override -writeSafelyToURL:…. This is the method that's actually
responsible for doing the special file-handling
Not sure what advantage that would give me generally speaking, but I'm using
background saving (by returning YES in -canAsynchronouslyWriteToURL:::). It
appears that -writeSafelyToURL: is being called on the background thread, while
the completion handler in -saveToURL:… is called on the main thread. I'll have
to think about the implications of that.
* You probably only want to ask the file wrapper to re-read if the operation
is a regular Save, Save As, or Autosave-in-place. For others, you want to
remain pointing at the original URLs I believe
OK, that sounds like a good idea, although my app doesn't support any save
operations other than Save and Save As (no versions, no autosaving).
One other question though, what does your writing code look like? Are you
overriding one of the -write… methods? Or implementing -fileWrapperOfType:…
?
Yes, I'm using -fileWrapperOfType::
- (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
{
NSFileWrapper *dataWrapper = [appData documentFileWrapper];
[self unblockUserInteraction];
return dataWrapper;
}
-documentFileWrapper basically prepares the wrappers (updates, replaces or
removes sub-wrappers as necessary).
Regards
Markus
--
__
Markus Spoettl
___
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: Ordering of Completion Handlers
On 01.09.2012, at 19:01, Seth Willits wrote: > On Sep 1, 2012, at 9:53 AM, Andreas Grosam wrote: > >> On 31.08.2012, at 19:35, Seth Willits wrote: >> >> Thank you very much Seth. It's a feasible approach. >> Your idea inspired me to a simple solution which is demonstrated in the >> running example below. >> >> There is only one caveat: each pending completion handler occupies a thread. > > No, they're stacked up in a serial queue so they're not all in their own > threads waiting to be fired. Yes, you'r right - I misinterpreted the debugger's thread view. Of course, the completion handler queue would only use one thread ;) Andreas ___ 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: NSDocument package saving invalidates wrapper? Options?
On 2 Sep 2012, at 08:04, Markus Spoettl wrote:
> On 9/1/12 10:23 PM, Mike Abdullah wrote:
>> It seems you're right; this is a side-effect of how NSDocument does
>> safe-saving. If the file wrappers internally hold onto the URL they were last
>> written to, that's no good if the file moves out underneath them. To cope
>> they'd have to be using a bookmark or file reference URL instead. Apple might
>> well be doing so in 10.8 or a later OS, but if you need to target 10.7, that
>> doesn't help!
>
> Thanks for the reply! Not sure I understand, are you saying in 10.8 this
> problem is non-existent? I don't see anything in the AppKit release notes
> indicating a change of behavior.
I was saying might have made the problem non-existent. I have absolutely no
idea if they have or not. But that if you're targeting 10.7 anyway, it's still
something you have to worry about.
>
>> I'd make two changes to your routine:
>
>> * Instead override -writeSafelyToURL:…. This is the method that's actually
>> responsible for doing the special file-handling
>
> Not sure what advantage that would give me generally speaking, but I'm using
> background saving (by returning YES in -canAsynchronouslyWriteToURL:::). It
> appears that -writeSafelyToURL: is being called on the background thread,
> while the completion handler in -saveToURL:… is called on the main thread.
> I'll have to think about the implications of that.
Well the main advantage is that you're keeping related code together.
-writeSafely… is responsible for doing the file swapping + temporary location
logic, so you might as well have your code for that alongside it.
Also, it's *possible* but unlikely for the doc system, or you being careless,
to call one of the older -save… methods instead of the new one.
>
>> * You probably only want to ask the file wrapper to re-read if the operation
>> is a regular Save, Save As, or Autosave-in-place. For others, you want to
>> remain pointing at the original URLs I believe
>
> OK, that sounds like a good idea, although my app doesn't support any save
> operations other than Save and Save As (no versions, no autosaving).
Any particular reason? It seems a shame not to adopt modern standards. You're
losing out on a nice degree of crash protection for a start.
>
>> One other question though, what does your writing code look like? Are you
>> overriding one of the -write… methods? Or implementing -fileWrapperOfType:…
>> ?
>
> Yes, I'm using -fileWrapperOfType::
>
> - (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
> **)outError
> {
>NSFileWrapper *dataWrapper = [appData documentFileWrapper];
>[self unblockUserInteraction];
>
>return dataWrapper;
> }
>
> -documentFileWrapper basically prepares the wrappers (updates, replaces or
> removes sub-wrappers as necessary).
Aha, so I'd say you have another alternative in which case:
You could implement -writeSafely… so that it calls straight through to
-writeToURL:…
Implement -writeToURL:… so that it calls -fileWrapperOfType:… and then writes
that out to the URL *atomically*
i.e. you'd be taking over responsibility for atomic saves by making
NSFileWrapper do it. That way the wrapper should neatly track where the files
really end up.
___
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: NSDocument package saving invalidates wrapper? Options?
On 9/2/12 1:12 PM, Mike Abdullah wrote:
On 9/1/12 10:23 PM, Mike Abdullah wrote:
It seems you're right; this is a side-effect of how NSDocument does
safe-saving. If the file wrappers internally hold onto the URL they were last
written to, that's no good if the file moves out underneath them. To cope
they'd have to be using a bookmark or file reference URL instead. Apple might
well be doing so in 10.8 or a later OS, but if you need to target 10.7, that
doesn't help!
Thanks for the reply! Not sure I understand, are you saying in 10.8 this
problem is non-existent? I don't see anything in the AppKit release notes
indicating a change of behavior.
I'd make two changes to your routine:
* Instead override -writeSafelyToURL:…. This is the method that's actually
responsible for doing the special file-handling
Not sure what advantage that would give me generally speaking, but I'm using
background saving (by returning YES in -canAsynchronouslyWriteToURL:::). It
appears that -writeSafelyToURL: is being called on the background thread, while
the completion handler in -saveToURL:… is called on the main thread. I'll have
to think about the implications of that.
* You probably only want to ask the file wrapper to re-read if the operation
is a regular Save, Save As, or Autosave-in-place. For others, you want to
remain pointing at the original URLs I believe
OK, that sounds like a good idea, although my app doesn't support any save
operations other than Save and Save As (no versions, no autosaving).
One other question though, what does your writing code look like? Are you
overriding one of the -write… methods? Or implementing -fileWrapperOfType:…
?
Yes, I'm using -fileWrapperOfType::
- (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
{
NSFileWrapper *dataWrapper = [appData documentFileWrapper];
[self unblockUserInteraction];
return dataWrapper;
}
-documentFileWrapper basically prepares the wrappers (updates, replaces or
removes sub-wrappers as necessary).
Actually, scratch my previous advice, I've just remembered what you should be
doing instead.
The user is free to move the document at any time. If NSDocument detects this,
it calls -setFileURL: as part of its work to keep up-to-date with the file on
disk.
So you need to override -setFileURL: to also ask your file wrapper to re-read
itself. This will happen if the user moves the document, but *also* after a
save operation. (I'm pretty certain it's for all save ops, not just Save As).
For example, NSPersistentDocument does this, using -setFileURL: as a cue to
update the persistent store's URL.
OK, thanks a lot for that tip. Even though I overwrote -setFileURL: for some
other task it never occurred to me to look if that's a better place. Feels very
natural actually. I find it extremely odd that the requirement to update file
wrapper isn't documented anywhere.
Regards
Markus
--
__
Markus Spoettl
___
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: Network and DarkWake
Are you using it in the asynchronous callback style, or the synchronous GetFlags function? This situation seems well-suited to the former, and if that's not working correctly, perhaps you should report a bug. -Matt Sent from my iPhone On Sep 2, 2012, at 2:53 AM, "Gerriet M. Denkmann" wrote: > > On 2 Sep 2012, at 12:34, Matt Patenaude wrote: > >> You might consider using SCNetworkReachability to monitor when the >> availability of time.apple.com changes. >> >> https://developer.apple.com/library/mac/#documentation/SystemConfiguration/Reference/SCNetworkReachabilityRef/Reference/reference.html > > I am already using this. > > But the problem seems to be: my app starts running again (because DarkWake), > then some time elapses, and finally everything is back to normal. > > Trying to use the network (getaddrinfo(), SCNetworkReachability or whatever) > before this point seems to lead to problems. > > What I really need is something like NSWorkspaceDidDarkWakeNotification which > is sent when everything is back to normal after a DarkWake. > But I could not find such a notification. > > Kind regards, > > Gerriet. > ___ 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: Network and DarkWake
On 2 Sep 2012, at 20:46, Matt Patenaude wrote: > Are you using it in the asynchronous callback style, or the synchronous > GetFlags function? I am using: SCNetworkReachabilitySetCallback() SCNetworkReachabilityScheduleWithRunLoop() Typical case: 2012-09-02 20:59:33.540 +0700 DidWakeNotification 2012-09-02 20:59:33.611 Error getaddrinfo(time.euro.apple.com, ntp) -> nodename nor servname provided, or not known 2012-09-02 20:59:37.354 lost internet connection 2012-09-02 20:59:37.375 newinternet connection 2012-09-02 20:59:37.391 try again - now everything is ok Seems like it just takes some time after wake (DarkWake or normal wake) for things to get sorted out. Gerriet. ___ 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
Prevent display of PDF controls in a WebView
In an OSX application, I use a WebView to display a variety of file types. When the type is PDF, something within Cocoa (PDFKit?) intercepts mouse movement in the lower portion of the screen and responds by displaying a translucent gray view with clickable areas that give options for the user to zoom in and out, open the file in Preview, or save it as a download. I see this on 10.8 but testers have reported it back to 10.6.8. (Part of my problem may be that I don't know what to call this element: contextual floating toolbar? ...hud panel? ...?) Anyway, I need to prevent it from appearing as it both interferes with how the program is supposed to function visually and gives options (zoom) that will cause incorrect program behavior if used. How is this thing activated and, much more important, how do I stop it? ___ 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
Code Signing for Mountain Lion
I'm just updating one of my more useful little tools (Locamatic) so that it is code signed for Mountain Lion. I know in advance that this program won't be suitable for the app store, firstly because it's a Preference Pane and secondly because it schedules shell scripts (packaged within the pref pane) to execute when certain conditions are met (gateway changes). I'd like to code sign it so that users can download it from my website and use it without breaching the default gatekeeper configuration though. I have two questions regarding this: 1. Do the internal shell scripts have to be signed separately (and as a corollary, can shell scripts be signed)? 2. When I sign the preference pane (using codesign) everything appears to be successful. When I verify with codesign, it returns nothing (which I understand to be a good thing). However, when I then download my finished prefpane to my test vm, also with Mountain Lion, it fails to pass GateKeeper (can't be opened because it is from an unidentified developer). What am I doing wrong? Thanks as always, and regards, Pascal ___ 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: Prevent display of PDF controls in a WebView
Have you investigated supplying your own PDF view. Webkit doesn't really offer anything about its built in PDF view beyond its existence. Sent from my iPad On 2 Sep 2012, at 06:32 PM, Phillip Mills wrote: > In an OSX application, I use a WebView to display a variety of file types. > When the type is PDF, something within Cocoa (PDFKit?) intercepts mouse > movement in the lower portion of the screen and responds by displaying a > translucent gray view with clickable areas that give options for the user to > zoom in and out, open the file in Preview, or save it as a download. > > I see this on 10.8 but testers have reported it back to 10.6.8. > > (Part of my problem may be that I don't know what to call this element: > contextual floating toolbar? ...hud panel? ...?) > > Anyway, I need to prevent it from appearing as it both interferes with how > the program is supposed to function visually and gives options (zoom) that > will cause incorrect program behavior if used. > > How is this thing activated and, much more important, how do I stop it? > > > ___ > > 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: Prevent display of PDF controls in a WebView
On 2012-09-02, at 4:16 PM, Mike Abdullah wrote: > Have you investigated supplying your own PDF view. Webkit doesn't really > offer anything about its built in PDF view beyond its existence. I thought about that. I've created my own view/representation pairs for two other (simple) data types but PDF sounded like something complex enough that letting the existing mechanism take care of it would be safer. Maybe not. Thanks for the suggestion. ___ 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: NSDocument package saving invalidates wrapper? Options?
On 9/2/12 10:12 PM, Mike Abdullah wrote: OK, thanks a lot for that tip. Even though I overwrote -setFileURL: for some other task it never occurred to me to look if that's a better place. Feels very natural actually. I find it extremely odd that the requirement to update file wrapper isn't documented anywhere. It seems the doc system assumes you generate the file wrapper afresh each save. Actually the Document Programming guide goes into details about file wrappers and talks about keeping them for faster IO: http://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/AdvancedTopics/AdvancedTopics.html#//apple_ref/doc/uid/TP40011179-CH7-SW10 Regards Markus -- __ Markus Spoettl ___ 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
Seeking advice re: placement of UndoManager
I am questioning where in the app I ought to locate my UndoManager code: 1) in the model classes? 2) in window controller class? 3) on its own as a controller-mediator class? The model is kvo compliant and so will be notified by observing itself. It has to broker the changes into the persistent store. Seems like a good locale to capture undo requirements. However it also seems like this is more a controller logic piece of the puzzle and as such doesn't really belong in the model classes. Advice from those who know would be much appreciated. Erik Stainsby erik.stain...@roaringsky.ca ___ 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: Prevent display of PDF controls in a WebView
On 2 Sep 2012, at 21:26, Phillip Mills wrote: > On 2012-09-02, at 4:16 PM, Mike Abdullah wrote: > >> Have you investigated supplying your own PDF view. Webkit doesn't really >> offer anything about its built in PDF view beyond its existence. > > I thought about that. I've created my own view/representation pairs for two > other (simple) data types but PDF sounded like something complex enough that > letting the existing mechanism take care of it would be safer. Maybe not. > > Thanks for the suggestion. I think PDFKit should make this pretty painless to implement. Never actually used it myself though I admit. ___ 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: Seeking advice re: placement of UndoManager
Forgot to mention this is not a NSDocument based app, nor am I using CD. OSX 10.8/deploying 10.7 Erik Stainsby erik.stain...@roaringsky.ca On 2012-09-02, at 3:10 PM, Erik Stainsby wrote: > I am questioning where in the app I ought to locate my UndoManager code: > > 1) in the model classes? > 2) in window controller class? > 3) on its own as a controller-mediator class? > > The model is kvo compliant and so will be notified by observing itself. It > has to broker the changes into the persistent store. Seems like a good locale > to capture undo requirements. However it also seems like this is more a > controller logic piece of the puzzle and as such doesn't really belong in the > model classes. > > Advice from those who know would be much appreciated. > > > Erik Stainsby > erik.stain...@roaringsky.ca > > ___ 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: Prevent display of PDF controls in a WebView
On 2 Sep 2012, at 18:32, Phillip Mills wrote: > In an OSX application, I use a WebView to display a variety of file types. > When the type is PDF, something within Cocoa (PDFKit?) intercepts mouse > movement in the lower portion of the screen and responds by displaying a > translucent gray view with clickable areas that give options for the user to > zoom in and out, open the file in Preview, or save it as a download. > > I see this on 10.8 but testers have reported it back to 10.6.8. > > (Part of my problem may be that I don't know what to call this element: > contextual floating toolbar? ...hud panel? ...?) > > Anyway, I need to prevent it from appearing as it both interferes with how > the program is supposed to function visually and gives options (zoom) that > will cause incorrect program behavior if used. > > How is this thing activated and, much more important, how do I stop it? You stand a good chance to get the desired results using a PDFView. I would subclass the PDFView to intercept the contextual menu (and not show any, if I understand what you need), and make sure commands like zoom in, zoom out and zoom actual don't make it through. There might be more you need to adjust, but off the top of my head, this should get you a great deal of the way there. Another consideration would be to use your own (non-PDFView subclass) view, and draw the PDF pages in there. Drawing a PDFPage into a view is fairly straightforward, but of course, creating your own PDF view is likely more work than subclassing and customizing the provided PDFView. -António --- Touch is a language without words --- ___ 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
Security-scoped bookmark feature?
I ran across an interesting behavior and potentially useful feature with security scoped bookmarks. I hadn't run across this in my reading before. Is this an official behavior? It turns out that once you've created an app-scoped bookmark for a file (after the user selected it in an OpenPanel), you can rename or move (same thing I guess) the file, and the bookmark still blesses it. And extracting the file path from the bookmark data gives you the new path, not the original one. So you can move the file around, and the program can still find it and access it through the bookmark. Pretty cool. Even if you weren't doing the bookmarking for sandboxing, I think it is a handy feature. Todd ___ 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: Seeking advice re: placement of UndoManager
On 03/09/2012, at 8:10 AM, Erik Stainsby wrote: > Advice from those who know would be much appreciated. I wouldn't say 'I know' at all, but I find that it is necessary to put the calls to the undo manager into the model. NSUndoManager's basic functionality acts on the model, but it also supports aspects of the view because it maintains the "action string" that is displayed in the Undo menu. As such you could say that it sits in the controller layer but unless the model tells it what to undo it can't do anything, so it relies on cooperation from the model. KVO is a good way to handle that (via some adapter class) because it's generic and so the model is not required to know about the undo manager itself - but a lot of model code predates KVO and talks to the undo manager directly (and there are some aspects of KVO that can make using it for undo awkward, like handling one-to-many relationship undos). If you're not using NSDocument, then you could make your undo manager a singleton, but bear in mind that standard Cocoa classes (e.g. NSTextView) will expect it to be returned by the window/window's delegate via -windowWillReturnUndoManager:, so you'd have to override that method to pass back your singleton. --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: Security-scoped bookmark feature?
On 03/09/2012, at 9:04 AM, Todd Heberlein wrote: > I ran across an interesting behavior and potentially useful feature with > security scoped bookmarks. I hadn't run across this in my reading before. Is > this an official behavior? > > It turns out that once you've created an app-scoped bookmark for a file > (after the user selected it in an OpenPanel), you can rename or move (same > thing I guess) the file, and the bookmark still blesses it. And extracting > the file path from the bookmark data gives you the new path, not the original > one. So you can move the file around, and the program can still find it and > access it through the bookmark. > > Pretty cool. Even if you weren't doing the bookmarking for sandboxing, I > think it is a handy feature. I think what you're really seeing is the benefit of bookmarks in general. They track files in the same way that olde-worlde aliases did. The security-scoping is a new graft-on for bookmarks, and presumably are applied after the bookmark has been resolved, and so I would expect the outcome you're seeing. --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: Code Signing for Mountain Lion
Pascal, I prepared a reply to your question but did not post because I realized this is too far off the topic of Cocoa. Please subscribe to apple-c...@lists.apple.com and re-post over there. You'll get better replies. ___ 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: core data stores, versioning
On 2012 Sep 01, at 04:20, Martin Hewitson wrote: > 1) Can one determine the version of a model from it's core data store file > (XML) ? > 2) Can one determine the corresponding version number of the models in Xcode ? If I remember correctly, models are identified by UUIDs. The normal method is to iterate through all the available models you have until you find one for which -[NSManagedObjectModel isConfiguration: compatibleWithStoreMetadata:]. You might learn something from here… https://github.com/jerrykrinock/ClassesObjC/blob/master/SSYPersistentDocumentMultiMigrator.m I think that the UUID itself is in the store's metadata, which you can learn how to dig into here… https://github.com/jerrykrinock/CategoriesObjC/blob/master/NSPersistentDocument%2BSSYMetadata.m > 3) Can one somehow reconstruct (if even by hand) a core data model from a > store file? It may be different with an XML store, but with an sqlite store, you could look at the tables in the store. Tables correspond to entities, etc. A GUI tool like SQLIteManager is handy. ___ 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: core data stores, versioning
Thanks for the links. In the end by comparing two XML files by hand, I was able to see that in my development version of the model one entity had a new property in it, which should only have been in version 3, but was in fact in both version 3 and version 2, and the user's data file was version 2. Anyway, thanks for the links and the clues. I could see the differences in the models by comparing the hashes of each entity. And a warning to others: I believe this happened because in some previous version of Xcode 4, when you added a model version, the new version appeared in the project navigator and was selected, but the version in the editor was still the previous version. And since one is a duplicate of the other, it's very easy to assume the editor has the new one, and start editing. I've since learned that I need to select some other file, then the new model version in the project navigator to ensure the editor is showing the correct model version. Not sure if this 'feature' still exists. Cheers, Martin On Sep 3, 2012, at 03:55 AM, Jerry Krinock wrote: > > On 2012 Sep 01, at 04:20, Martin Hewitson wrote: > >> 1) Can one determine the version of a model from it's core data store file >> (XML) ? >> 2) Can one determine the corresponding version number of the models in Xcode >> ? > > If I remember correctly, models are identified by UUIDs. The normal method > is to iterate through all the available models you have until you find one > for which -[NSManagedObjectModel isConfiguration: > compatibleWithStoreMetadata:]. You might learn something from here… > > https://github.com/jerrykrinock/ClassesObjC/blob/master/SSYPersistentDocumentMultiMigrator.m > > I think that the UUID itself is in the store's metadata, which you can learn > how to dig into here… > > https://github.com/jerrykrinock/CategoriesObjC/blob/master/NSPersistentDocument%2BSSYMetadata.m > >> 3) Can one somehow reconstruct (if even by hand) a core data model from a >> store file? > > It may be different with an XML store, but with an sqlite store, you could > look at the tables in the store. Tables correspond to entities, etc. A GUI > tool like SQLIteManager is handy. > > > > ___ > > 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/martin.hewitson%40aei.mpg.de > > This email sent to martin.hewit...@aei.mpg.de smime.p7s Description: S/MIME cryptographic signature ___ 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
