dispatch_apply strange results
I am trying to optimise a Cocoa app which spends most of it's time in a
for-loop looking at the bytes of a huge array.
So I decided to use dispatch_apply to divide the work of the for-loop onto
different cpus (I seem to have 8 of them).
Note: no two threads ever share a common byte of this array.
When I just count the bytes, it behaves as expected: using more threads makes
it work faster:
# count (no modify) 999888777 bytes in 1 ... 5 threads
1 2.28948
2 1.31898
3 0.889931
4 0.736646
5 0.799812
But when the for-loop also modifies the byte array, then I get:
# count and modify 999888777 bytes in 1 ... 5 threads
1 2.26273
2 3.62382
3 2.41613
4 2.11105
5 2.54171
Here, using only one thread takes about the same time as before. Not very
surprising.
But using two threads takes much longer than just using one!
How could this happen?
The code is:
- (IBAction)doClicked: sender
{
BOOL alsoModify = self.selectedMode == mod_CountModify;
fprintf(stderr,"\n# count %s %lu bytes in %lu ... %lu threads\n",
alsoModify ? "and modify" : "(no modify)", self.nbrBytes,
self.minThread, self.maxThread);
size_t arraySize = self.nbrBytes * sizeof(unsigned char);
unsigned char *byteArray = malloc( arraySize );
memset( byteArray, 1, arraySize );
NSUInteger sums[self.maxThread];
NSUInteger *sumPointer = sums;
dispatch_queue_t queue = dispatch_get_global_queue(
DISPATCH_QUEUE_PRIORITY_HIGH, 0 );
for( size_t nbrThreads = self.minThread; nbrThreads <= self.maxThread;
nbrThreads++ )
{
NSDate *date = [ NSDate date ];
NSUInteger bytesPerThread = _nbrBytes / nbrThreads;
NSUInteger bytesInLastThread = _nbrBytes - bytesPerThread * (
nbrThreads - 1 );
for( NSUInteger i = 0; i < nbrThreads; i++ ) sums[i] = 0;
dispatch_apply( nbrThreads, queue, ^void(size_t idx)
{
NSUInteger start = idx * bytesPerThread;
NSUInteger len = idx + 1 == nbrThreads ?
bytesInLastThread : bytesPerThread;
NSUInteger *threadSumPointer = sumPointer + idx
;
for( NSUInteger i = 0; i < len; i++ )
{
*threadSumPointer += byteArray[ start +
i ];
if ( alsoModify ) byteArray[ start + i
] &= 0xf;
};
}
);
NSUInteger total = 0; for( NSUInteger i = 0; i < nbrThreads;
i++ ) total += sums[i];
NSTimeInterval elapsedTime = -[ date timeIntervalSinceNow ];
fprintf(stderr,"%lu\t%g\n", nbrThreads, elapsedTime);
};
free( byteArray );
}
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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 7:31 PM, David Delmonte wrote: > > That's my understanding as well. So what to do? Pretty clear that you can’t sell the app via the App Store. You could sell it via your own site (with proper code signing so that Gatekeeper lets you through). Or you could reconsider whether you need to elevate your privileges. --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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
That's my understanding as well. So what to do? On Feb 8, 2014, at 10:21 PM, SevenBits wrote: On Saturday, February 8, 2014, David Delmonte wrote: > Good advice. Thanks Jens. Do you know of any samples that employ good > behavior? > > Right now, I'm playing with SMJobBless. > > Finally, does anyone know if the Mac App Store would accept an app with > elevated permissions (admin permissions to enter a password)? (or am I > confusing things?) Apple's MAS review guidelines state that apps that attempt to elevate permissions to root (ergo, apps that use the Authentication API) will be rejected. So it's a safe bet to assume that it won't be accepted. > > On Feb 8, 2014, at 7:26 PM, Jens Alfke > > wrote: > > > On Feb 8, 2014, at 2:51 PM, David Delmonte > > wrote: > >> Yep, I'm implementing "EvenBetterAuthorizationSample" code now. Does > make me sad to have to do this. I help older people use technology. They > are always forgetting their passwords. Just trying to help.. > > The best way to do this would be to write a friendlier app similar to > Keychain Access. I use that app all the time to look up passwords, but it > takes a number of steps to do so and it's not terribly intuitive. > > Browsers are pretty good about adding passwords to the Keychain. At least > Safari and Chrome are; I think Firefox might have its own password store > (boo). They're not always as good about filling in passwords for you again > afterwards, although Safari 7 has gotten better. So it's sometimes > necessary to look them up from the Keychain. > > Writing an app that will store passwords in some other way is a bad idea. > It's pretty much guaranteed to be less secure than the Keychain, which has > some kernel-level support for helping keep its storage secure. The Keychain > also has other advantages like syncing to iCloud and to iOS devices, in a > fairly secure way. > > (Sorry if I sound heavy-handed; nothing personal. I've been coding with a > security-conscious mindset for quite a while now, and it sticks with you. > Security is becoming increasingly important, and all developers whose code > ever touches things like passwords should be following good practices.) > > --Jens > > ___ > > 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/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.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/ddelmonte%40mac.com This email sent to ddelmo...@mac.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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Saturday, February 8, 2014, David Delmonte wrote: > Good advice. Thanks Jens. Do you know of any samples that employ good > behavior? > > Right now, I'm playing with SMJobBless. > > Finally, does anyone know if the Mac App Store would accept an app with > elevated permissions (admin permissions to enter a password)? (or am I > confusing things?) Apple's MAS review guidelines state that apps that attempt to elevate permissions to root (ergo, apps that use the Authentication API) will be rejected. So it's a safe bet to assume that it won't be accepted. > > On Feb 8, 2014, at 7:26 PM, Jens Alfke > > wrote: > > > On Feb 8, 2014, at 2:51 PM, David Delmonte > > wrote: > > > Yep, I'm implementing "EvenBetterAuthorizationSample" code now. Does > make me sad to have to do this. I help older people use technology. They > are always forgetting their passwords. Just trying to help.. > > The best way to do this would be to write a friendlier app similar to > Keychain Access. I use that app all the time to look up passwords, but it > takes a number of steps to do so and it's not terribly intuitive. > > Browsers are pretty good about adding passwords to the Keychain. At least > Safari and Chrome are; I think Firefox might have its own password store > (boo). They're not always as good about filling in passwords for you again > afterwards, although Safari 7 has gotten better. So it's sometimes > necessary to look them up from the Keychain. > > Writing an app that will store passwords in some other way is a bad idea. > It's pretty much guaranteed to be less secure than the Keychain, which has > some kernel-level support for helping keep its storage secure. The Keychain > also has other advantages like syncing to iCloud and to iOS devices, in a > fairly secure way. > > (Sorry if I sound heavy-handed; nothing personal. I've been coding with a > security-conscious mindset for quite a while now, and it sticks with you. > Security is becoming increasingly important, and all developers whose code > ever touches things like passwords should be following good practices.) > > --Jens > > ___ > > 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/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.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: Managing image loading
On Feb 8, 2014, at 3:58 AM, Leonardo wrote: > When the user imports a new image, I quickly copy the image to a temporary > folder, then I add this latest file reference to the document’s NSFileWrapper. > I just create the file’s fileWrapper using its URL, so I do not read its > content and create the fileWrapper by the NSData. This seems like a hacky workaround for the kind of temporary storage that you'd already get from virtual memory. See below. > Why don’t I add the file’s NSData to the fileWrapper but I add just its URL > reference? Because I don’t really know whether the fileWrapper uses the disk > or keeps the NSData in memory. So in case of a 1GB file I do not engulf the > app. It's a 64-bit app, presumably, so you have no worries about running out of address space. If physical RAM is running low, then the OS will just write part of your address space to disk to make room; when you access that address space again, it'll read it back in. Basically the virtual memory system is going to do what your temporary-file-copying solution would have done, only it's doing it more efficiently because (a) it only writes it to disk if there's not enough RAM; (b) it only copies as much of the data as needed; and (c) it'll free up that disk space automatically later on. I think I asked this before, but: Do you already have a running app that is having performance problems working with large or lots of images? Or are you simply imagining that your app might run into these problems, without knowing whether that's true? In the latter case, _especially_ if you're a novice developer or new to the platform, please put off worrying about performance until later. —Jens ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
Good advice. Thanks Jens. Do you know of any samples that employ good behavior? Right now, I'm playing with SMJobBless. Finally, does anyone know if the Mac App Store would accept an app with elevated permissions (admin permissions to enter a password)? (or am I confusing things?) On Feb 8, 2014, at 7:26 PM, Jens Alfke wrote: On Feb 8, 2014, at 2:51 PM, David Delmonte wrote: > Yep, I'm implementing "EvenBetterAuthorizationSample" code now. Does make me > sad to have to do this. I help older people use technology. They are always > forgetting their passwords. Just trying to help.. The best way to do this would be to write a friendlier app similar to Keychain Access. I use that app all the time to look up passwords, but it takes a number of steps to do so and it's not terribly intuitive. Browsers are pretty good about adding passwords to the Keychain. At least Safari and Chrome are; I think Firefox might have its own password store (boo). They're not always as good about filling in passwords for you again afterwards, although Safari 7 has gotten better. So it's sometimes necessary to look them up from the Keychain. Writing an app that will store passwords in some other way is a bad idea. It's pretty much guaranteed to be less secure than the Keychain, which has some kernel-level support for helping keep its storage secure. The Keychain also has other advantages like syncing to iCloud and to iOS devices, in a fairly secure way. (Sorry if I sound heavy-handed; nothing personal. I've been coding with a security-conscious mindset for quite a while now, and it sticks with you. Security is becoming increasingly important, and all developers whose code ever touches things like passwords should be following good practices.) —Jens ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 2:51 PM, David Delmonte wrote: > Yep, I'm implementing "EvenBetterAuthorizationSample" code now. Does make me > sad to have to do this. I help older people use technology. They are always > forgetting their passwords. Just trying to help.. The best way to do this would be to write a friendlier app similar to Keychain Access. I use that app all the time to look up passwords, but it takes a number of steps to do so and it's not terribly intuitive. Browsers are pretty good about adding passwords to the Keychain. At least Safari and Chrome are; I think Firefox might have its own password store (boo). They're not always as good about filling in passwords for you again afterwards, although Safari 7 has gotten better. So it's sometimes necessary to look them up from the Keychain. Writing an app that will store passwords in some other way is a bad idea. It's pretty much guaranteed to be less secure than the Keychain, which has some kernel-level support for helping keep its storage secure. The Keychain also has other advantages like syncing to iCloud and to iOS devices, in a fairly secure way. (Sorry if I sound heavy-handed; nothing personal. I've been coding with a security-conscious mindset for quite a while now, and it sticks with you. Security is becoming increasingly important, and all developers whose code ever touches things like passwords should be following good practices.) —Jens ___ 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: Design pattern for bulk data handling
On Feb 8, 2014, at 2:54 PM, Tito Ciuro wrote: > For even more speed, consider turning off the following setting: > http://www.sqlite.org/pragma.html#pragma_synchronous (This is getting slightly off-topic, but…) The only time I'd set synchronous to OFF is while populating a _new_ database file, as part of some sort of "safe save" process where you create the file in a temporary directory, write to it, and only move it into the real directory at the end. Basically when synchronous is OFF it's entirely possible that a power failure or kernel panic could corrupt the database. (I've seen this happen several times. It's not just theoretical.) So don't use it on a database file that has any data you mind losing, or that's in a location where the user might try to re-open it later (because if she does, you'll get a support ticket about your app crashing or failing to open the file.) —Jens ___ 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: Design pattern for bulk data handling
Also, consider dropping the table indexes before you start inserting. After the you're done inserting, rebuild the indexes. This should give you an an additional performance boost. For even more speed, consider turning off the following setting: http://www.sqlite.org/pragma.html#pragma_synchronous *warning*: read the link carefully and understand what it does before using it! -- Tito > On Feb 8, 2014, at 14:25, Jens Alfke wrote: > > >> On Feb 8, 2014, at 10:20 AM, Ben wrote: >> >> This is fine for most things, except that I sometimes need faster access to >> the underlying database - for example, when importing/exporting data. In >> these cases I'm after bulk data throughput without the overhead of >> creating/destroying many NSOperations with completion handlers since there >> can be in the order of millions of statements to handle. > > You can read arbitrarily large amounts of data with a single statement, so > that's not an issue. But in general it takes many statements to insert a lot > of rows. (And for performance reasons you really want to group all of those > statements in a single transaction, or you'll lose an order of magnitude of > performance.) > > What I'd do is provide a new operation type that does a bulk-insert or > bulk-update. When run the operation performs a series of SQL statements > starting with a "BEGIN" and ending with an "END". > > —Jens > ___ > > 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/tciuro%40mac.com > > This email sent to tci...@mac.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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 5:22 PM, Jens Alfke wrote: On Feb 8, 2014, at 12:04 PM, David Delmonte wrote: > However, this app is being designed for use at home - or - I admit - on > portables. This is not a corporate entity. Doesn't matter. Individual people have just as much right to security as corporations do. Home computers get hacked in large numbers, often with key-logging software installed to capture passwords. NSSecureTextField helps deter this. hmm. understood. > I'm not claiming my app is secure: "It's a bit better than writing your > password on an envelope". Um … what is this app supposed to do? And what does it do with the passwords? You can do a lot better than disclaiming all responsibility for security. If you're making the app _look_ secure, with password entry, it should be at least somewhat secure. Apple already provides you with a very secure storage system for passwords (and other sensitive bits of data), the Keychain. Yep, I'm implementing "EvenBetterAuthorizationSample" code now. Does make me sad to have to do this. I help older people use technology. They are always forgetting their passwords. Just trying to help.. > I am wondering what UI people think about hidden passwords. Don't they annoy > you when you cant see what your typing? They do me, but I'm old and grumpy. Security and usability are often at odds. Ideally we wouldn't have to hide password typing or put up confusing security alerts when people launch apps, etc. But in the real world they're necessary, and part of the job of UI design is to make those trade-offs in the cleanest way possible. There's been rather a lot written about this — O'Reilly has a good book called "Security And Usability" for example. Thanks for the link to the book. I will look at it, ok read it. Watching someone's screen or typing to discover their password is a classic and common theft technique — it's called "shoulder surfing". Hiding their password as they enter it, wont deter someone who can follow keyboard strokes - especially an older person who types one letter every 5 seconds or so.. But thanks to everyone who answered. I am taking advice. —Jens ___ 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: Design pattern for bulk data handling
On Feb 8, 2014, at 10:20 AM, Ben wrote: > This is fine for most things, except that I sometimes need faster access to > the underlying database - for example, when importing/exporting data. In > these cases I'm after bulk data throughput without the overhead of > creating/destroying many NSOperations with completion handlers since there > can be in the order of millions of statements to handle. You can read arbitrarily large amounts of data with a single statement, so that's not an issue. But in general it takes many statements to insert a lot of rows. (And for performance reasons you really want to group all of those statements in a single transaction, or you'll lose an order of magnitude of performance.) What I'd do is provide a new operation type that does a bulk-insert or bulk-update. When run the operation performs a series of SQL statements starting with a "BEGIN" and ending with an "END". —Jens ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 12:04 PM, David Delmonte wrote: > However, this app is being designed for use at home - or - I admit - on > portables. This is not a corporate entity. Doesn't matter. Individual people have just as much right to security as corporations do. Home computers get hacked in large numbers, often with key-logging software installed to capture passwords. NSSecureTextField helps deter this. > I'm not claiming my app is secure: "It's a bit better than writing your > password on an envelope". Um … what is this app supposed to do? And what does it do with the passwords? You can do a lot better than disclaiming all responsibility for security. If you're making the app _look_ secure, with password entry, it should be at least somewhat secure. Apple already provides you with a very secure storage system for passwords (and other sensitive bits of data), the Keychain. > I am wondering what UI people think about hidden passwords. Don't they annoy > you when you cant see what your typing? They do me, but I'm old and grumpy. Security and usability are often at odds. Ideally we wouldn't have to hide password typing or put up confusing security alerts when people launch apps, etc. But in the real world they're necessary, and part of the job of UI design is to make those trade-offs in the cleanest way possible. There's been rather a lot written about this — O'Reilly has a good book called "Security And Usability" for example. Watching someone's screen or typing to discover their password is a classic and common theft technique — it's called "shoulder surfing". —Jens ___ 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: NSToolbar delegate -toolbarAllowedItemIdentifiers:
On 2/8/14 12:25 AM, Quincey Morris wrote: It’s a while since I had to suffer through the pain that is NSToolbar delegate methods, but I suspect the problem is that the IB-created items are in a different universe from programmatically created ones. Therefore, in a “mixed” configuration, ‘toolbarAllowedItemIdentifiers:’ is queried only to supply the identifiers of non-IB items that you want to add to the IB-defined toolbar. The delegate method is, after all, optional *in this case*. If that’s correct, and you have a toolbar whose items are allowed in a *contextually* dependent way, you’ll have to create the toolbar contents programmatically — or at least those items. Note that I’m speculating. I vaguely recall that there was something very horrible about mixing IB and non-IB items, and this may or may not be it. Yes, horrible comes to mind. I ended up duplicating the entire toolbar so it's constructed at runtime - with embedded segmented controls that's a lot of fun. That was only way to make it work. Unfortunately I can't even use the same toolbar identifier (for auto-configuration saving purposes), because even though -toolbarAllowedItemIdentifiers: returns a reduced set, NSToolbar will reconstruct items with identifiers not currently allowed when restoring a toolbar configuration that was stored when all items were allowed. 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: makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion
On 2/8/14 9:31 PM, Markus Spoettl wrote:
On 2/8/14 8:43 PM, Trygve Inda wrote:
I am reading a document in the format of the old version of my app and
converting it to a new format. The old version is not a document at all but
is a fixed data file in /Application Support/MyApp/
MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
makeDocumentForURL:nil withContentsOfURL:fileURL
ofType:kApplicationDocumentType error:&error];
if (untitledDoc)
{
[untitledDoc makeWindowControllers];
[untitledDoc showWindows];
[untitledDoc setFileURL:nil];
[[NSDocumentController sharedDocumentController] addDocument:(NSDocument
*)untitledDoc];
}
I have something similar (loading an old file into a document with blank file
URL) but instead of do driving the whole documentation creation manually, I let
AppKit do it the way it wants to do it.
In other words, have you tried calling -openDocument: on your
NSDocumentController setting fileURL to nil when it is done?
Meant to say -openDocumentWithContentsOfURL:::
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: makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion
On 2/8/14 8:43 PM, Trygve Inda wrote:
I am reading a document in the format of the old version of my app and
converting it to a new format. The old version is not a document at all but
is a fixed data file in /Application Support/MyApp/
MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
makeDocumentForURL:nil withContentsOfURL:fileURL
ofType:kApplicationDocumentType error:&error];
if (untitledDoc)
{
[untitledDoc makeWindowControllers];
[untitledDoc showWindows];
[untitledDoc setFileURL:nil];
[[NSDocumentController sharedDocumentController] addDocument:(NSDocument
*)untitledDoc];
}
I have something similar (loading an old file into a document with blank file
URL) but instead of do driving the whole documentation creation manually, I let
AppKit do it the way it wants to do it.
In other words, have you tried calling -openDocument: on your
NSDocumentController setting fileURL to nil when it is done?
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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
I am deferring to the expertise here and will use Mike Abdullah's password logic. However, this app is being designed for use at home - or - I admit - on portables. This is not a corporate entity. I'm not claiming my app is secure: "It's a bit better than writing your password on an envelope". I am wondering what UI people think about hidden passwords. Don't they annoy you when you cant see what your typing? They do me, but I'm old and grumpy. On Feb 8, 2014, at 1:27 PM, Gary L. Wade wrote: Very true, and that's why I asked Apple in a Radar to fix it since, if it CAN be done, they're more in a position to do it (masters of the hardware and software) than relying upon each developer to make secondary screens. Maybe the hint text could be a layer not available for secondary device consumption on top of the actual bullet being displayed? Maybe a bit slow/cumbersome and possibly only activated when a secondary screen is used, but that's how I might start out trying to do it myself. I haven't tried it myself, but I wonder if screenshots are only possible with the bullet and no hint text; maybe a tie-in? It's all academic for us; this needs to be addressed by Apple, so file your Radar you've been threatening to do, and maybe it'll make the next upgrade. -- Gary L. Wade http://www.garywade.com/ On 2/8/2014 10:10 AM, "Kyle Sluder" wrote: > On Feb 8, 2014, at 10:06 AM, "Gary L. Wade" > wrote: >> >> Yeah, that demo issue came up yesterday, so I filed my own >> rdar://16013973 >> and as you know, it always helps to add duplicates! I marked mine as an >> issue with Security and Always. I suggested only showing the hints on >> the >> actual device and doing a secondary broadcast without the hint on >> secondary devices, especially simulators and AirPlay similar to how the >> old DVD anti-copy-protection thing worked. > > AirPlay mirroring is done in hardware, IIRC. App authors have the ability > to create a second screen and put the AirPlay content there, but for apps > that don¹t do that the OS just feeds data from the GPU framebuffer to the > MPEG encoder. It needs to be turned off on all screens if AirPlay is > active. > > --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
makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion
I am reading a document in the format of the old version of my app and
converting it to a new format. The old version is not a document at all but
is a fixed data file in /Application Support/MyApp/
MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
makeDocumentForURL:nil withContentsOfURL:fileURL
ofType:kApplicationDocumentType error:&error];
if (untitledDoc)
{
[untitledDoc makeWindowControllers];
[untitledDoc showWindows];
[untitledDoc setFileURL:nil];
[[NSDocumentController sharedDocumentController] addDocument:(NSDocument
*)untitledDoc];
}
This works fine and I am able to migrate the data into a real NSDocument
subclass.
However, if I close the window (thus closing the document) and choose to not
save, the file package at fileURL is deleted.
Yikes!
How can I completely disassociate the fileURL from the new document that I
created. I want to treat fileURL as a template or stationary that is only
read from, and never written to.
[untitledDoc setFileURL:nil] does not seem to work to disassociate the
document from the source file.
Thanks,
Trygve
___
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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
Very true, and that's why I asked Apple in a Radar to fix it since, if it CAN be done, they're more in a position to do it (masters of the hardware and software) than relying upon each developer to make secondary screens. Maybe the hint text could be a layer not available for secondary device consumption on top of the actual bullet being displayed? Maybe a bit slow/cumbersome and possibly only activated when a secondary screen is used, but that's how I might start out trying to do it myself. I haven't tried it myself, but I wonder if screenshots are only possible with the bullet and no hint text; maybe a tie-in? It's all academic for us; this needs to be addressed by Apple, so file your Radar you've been threatening to do, and maybe it'll make the next upgrade. -- Gary L. Wade http://www.garywade.com/ On 2/8/2014 10:10 AM, "Kyle Sluder" wrote: >On Feb 8, 2014, at 10:06 AM, "Gary L. Wade" > wrote: >> >> Yeah, that demo issue came up yesterday, so I filed my own >>rdar://16013973 >> and as you know, it always helps to add duplicates! I marked mine as an >> issue with Security and Always. I suggested only showing the hints on >>the >> actual device and doing a secondary broadcast without the hint on >> secondary devices, especially simulators and AirPlay similar to how the >> old DVD anti-copy-protection thing worked. > >AirPlay mirroring is done in hardware, IIRC. App authors have the ability >to create a second screen and put the AirPlay content there, but for apps >that don¹t do that the OS just feeds data from the GPU framebuffer to the >MPEG encoder. It needs to be turned off on all screens if AirPlay is >active. > >--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
Design pattern for bulk data handling
Hi list, I'm looking for the right design pattern for providing different types of access to an SQLite database. Currently I have a database object where queries are run on a serial NSOperationQueue and each operation has a completion block for reporting its results. The operation queue is an implementation detail behind a more basic API. This is fine for most things, except that I sometimes need faster access to the underlying database - for example, when importing/exporting data. In these cases I'm after bulk data throughput without the overhead of creating/destroying many NSOperations with completion handlers since there can be in the order of millions of statements to handle. In the past I had simply broken encapsulation by exposing the underlying database engine API. I'd rather find a better method than this for the future. Options considered so far: 1. Continue exposing underlying DB engine 2. Add a simpler synchronous API for use on a separate thread 3. Expose NSOperationQueue and allow custom import operations to be queued 4. Add importing functions to the database object itself Does anyone have any suggestions as to how best to approach this problem? - Ben ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 10:39 AM, David Delmonte wrote: > When the user enters a new password, it overwrites the asterisks (I'll > change them to bullets), and the user can see what he/she is writing. I never > understood why people can't see what they are typing in. — So the folks standing behind you (don’t think that they aren’t there) can’t see your password. — So Applescript, et al, cannot snarf the password from the field. Steve Bird Culverson Software - Elegant software that is a pleasure to use. www.Culverson.com (toll free) 1-877-676-8175 ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 10:06 AM, "Gary L. Wade" wrote: > > Yeah, that demo issue came up yesterday, so I filed my own rdar://16013973 > and as you know, it always helps to add duplicates! I marked mine as an > issue with Security and Always. I suggested only showing the hints on the > actual device and doing a secondary broadcast without the hint on > secondary devices, especially simulators and AirPlay similar to how the > old DVD anti-copy-protection thing worked. AirPlay mirroring is done in hardware, IIRC. App authors have the ability to create a second screen and put the AirPlay content there, but for apps that don’t do that the OS just feeds data from the GPU framebuffer to the MPEG encoder. It needs to be turned off on all screens if AirPlay is active. --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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
Yeah, that demo issue came up yesterday, so I filed my own rdar://16013973 and as you know, it always helps to add duplicates! I marked mine as an issue with Security and Always. I suggested only showing the hints on the actual device and doing a secondary broadcast without the hint on secondary devices, especially simulators and AirPlay similar to how the old DVD anti-copy-protection thing worked. -- Gary L. Wade http://www.garywade.com/ On 2/8/2014 9:56 AM, "Kyle Sluder" wrote: >On Feb 8, 2014, at 5:37 AM, David Delmonte wrote: >> >> I realized I could do this: 1. use just an NSTextField, and 2. if >>(hiding) textField.stringValue = @"**"; >> Is there something I'm missing? > >Please don't do this. NSSecureTextFieldCell uses a custom field editor >that protects the password from being snarled via Accessibility or event >taps. > >Also, computer screens are much more likely to be visible to other people >than phone screens, and people in general are more confident typists on >physical keyboards than on virtual ones. Showing characters as they type >is doing a disservice. (In fact, now that AirPlay Mirroring is so >prevalent, I've been meaning to file a Radar asking Apple to remove the >³show last character typed² feature from UIKit.) > >--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: Managing image loading
On Feb 8, 2014, at 3:58 AM, Leonardo wrote: > > I had to scratch my head at managing the undo, but I found a solution here > too. > When the user undo the import of an image, if the images has been never > saved, so it is still within the temporary folder, I just remove the image > file reference from the fileWrapper. Instead, if the image has already been > saved, so it is within the file package, I copy its file to the temporary > folder and remove its reference from the fileWrapper. So when the user saves > the doc, the image file get removed from the doc filePackage. And if the > user invokes the undo, I add the temp image file to the fileWrapper. > It sounds complicated but it works well. This will break. > > Why do I use a temporary folder? Because if the user imports an image file > then he tries to delete the original image file, the OS tells him that he > can¹t delete that file in use. That could be annoying. Except the file *is* in use—a reference to it lives on your undo stack. You seem not to care about data corruption. But it turns out this doesn’t matter, because your NSData will have an open file descriptor on the image file, so deleting it via Finder won’t actually delete the file from disk until the NSData instance is reallocated or your app quits. The only thing that would be problematic would be ejecting the volume the file lives on—the OS should warn about that. So you need to handle the case that the file gets deleted while its data is still on the undo stack. You won't be able to swap the file back into place. See below for how to address that: > Why don¹t I add the file¹s NSData to the fileWrapper but I add just its URL > reference? Because I don¹t really know whether the fileWrapper uses the disk > or keeps the NSData in memory. So in case of a 1GB file I do not engulf the > app. 1. Look up “memory mapping.” You can pass arguments to NSData that control whether it maps the image file. 2. The wonderful thing about virtual memory is that it gets paged out to disk. 3. 64-bit apps have oodles of address space (256TB under the current scheme); dedicating 1GB of that to a memory-mapped image file is not going to be a problem. --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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Feb 8, 2014, at 5:37 AM, David Delmonte wrote: > > I realized I could do this: 1. use just an NSTextField, and 2. if (hiding) > textField.stringValue = @"**"; > Is there something I'm missing? Please don't do this. NSSecureTextFieldCell uses a custom field editor that protects the password from being snarled via Accessibility or event taps. Also, computer screens are much more likely to be visible to other people than phone screens, and people in general are more confident typists on physical keyboards than on virtual ones. Showing characters as they type is doing a disservice. (In fact, now that AirPlay Mirroring is so prevalent, I've been meaning to file a Radar asking Apple to remove the “show last character typed” feature from UIKit.) --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: NSWindow remember whether showing on re-launch
On Feb 8, 2014, at 9:45 AM, Michael Babin wrote: > On Feb 7, 2014, at 11:43 PM, Roland King wrote: > >> I have a window in my OSX application which shows a log of commands. It's >> not 'Visible At Launch' because you often don't need to see it. It's also >> excluded from the windows menu, instead it has its own permanent menu item >> on that menu which both shows if it's enabled and acts as a menu item to >> toggle it. All works fine. >> >> I want however the window to remember its state and if it was showing when >> the app was terminated, show on re-start. I can do that with a user default >> quite easily but figured this has to be a very common task and thought there >> must be a standard way to accomplish it. Is there? > > Have you read the section of the Mac App Programming Guide on UI preservation? > > User Interface Preservation Well, that looked like a link when I pasted it in my original message but apparently did not get included or sent as such. Here it is again: https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW26 > > Also see the related reference items (NSWindowRestoration protocol, NSWindow > and NSResponder classes). For standard window state (size, position, > visible), I suspect the state preservation/restoration of NSWindow itself > would suffice (as long as the window is restorable). ___ 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: NSWindow remember whether showing on re-launch
On Feb 7, 2014, at 11:43 PM, Roland King wrote: > I have a window in my OSX application which shows a log of commands. It's not > 'Visible At Launch' because you often don't need to see it. It's also > excluded from the windows menu, instead it has its own permanent menu item on > that menu which both shows if it's enabled and acts as a menu item to toggle > it. All works fine. > > I want however the window to remember its state and if it was showing when > the app was terminated, show on re-start. I can do that with a user default > quite easily but figured this has to be a very common task and thought there > must be a standard way to accomplish it. Is there? Have you read the section of the Mac App Programming Guide on UI preservation? User Interface Preservation Also see the related reference items (NSWindowRestoration protocol, NSWindow and NSResponder classes). For standard window state (size, position, visible), I suspect the state preservation/restoration of NSWindow itself would suffice (as long as the window is restorable). ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
@Mike. Thanks I'll look at this - I knew I wouldn't have to reinvent the wheel. However: @Uli. My little solution actually works rather nicely (at least in Greek and English). When the user enters a new password, it overwrites the asterisks (I'll change them to bullets), and the user can see what he/she is writing. I never understood why people can't see what they are typing in. When the user subsequently moves to a new field or record, the password field is then hidden. By the way, I've read articles and help messages you have all sent over the years, as I try to catch up with Cocoa. I find it really impressive how long you have been at it, and how long you have been helping each other, and people like me. I still find messages from 10 years ago or more that seem just as relevant and useful today. Thanks! On Feb 8, 2014, at 10:30 AM, Mike Abdullah wrote: http://www.mikeabdullah.net/kspasswordfield.html On 8 Feb 2014, at 00:27, David Delmonte wrote: > Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like > users to have the option to see their passwords. > In iOS, I can do something like [textField setSecureTextEntry:YES]; > > I found [secureTextField setEchoBullets] but that's not what I want. > > > > Thanks > ___ > > 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/mabdullah%40karelia.com > > This email sent to mabdul...@karelia.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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
http://www.mikeabdullah.net/kspasswordfield.html On 8 Feb 2014, at 00:27, David Delmonte wrote: > Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like > users to have the option to see their passwords. > In iOS, I can do something like [textField setSecureTextEntry:YES]; > > I found [secureTextField setEchoBullets] but that's not what I want. > > > > Thanks > ___ > > 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/mabdullah%40karelia.com > > This email sent to mabdul...@karelia.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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On 08 Feb 2014, at 14:37, David Delmonte wrote: > On Feb 7, 2014, at 7:44 PM, Kyle Sluder wrote: >> On Fri, Feb 7, 2014, at 04:27 PM, David Delmonte wrote: >>> Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like >>> users to have the option to see their passwords. >>> In iOS, I can do something like [textField setSecureTextEntry:YES]; >>> >>> I found [secureTextField setEchoBullets] but that's not what I want. >> >> No. You'll have to swap between instances of NSTextField and >> NSSecureTextField, keeping the two controls' stringValues in sync. > I realized I could do this: 1. use just an NSTextField, and 2. if (hiding) > textField.stringValue = @"**"; > Is there something I'm missing? How will you get whatever string the user entered into the field if you replace it with bullets (I hope you plan to use bullets, not asterisks)? What if the user selects the first character and replaces it with a new one? Have you thought about international character sets like Japanese or Hebrew? Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
I realized I could do this: 1. use just an NSTextField, and 2. if (hiding) textField.stringValue = @"**"; Is there something I'm missing? On Feb 7, 2014, at 7:44 PM, Kyle Sluder wrote: On Fri, Feb 7, 2014, at 04:27 PM, David Delmonte wrote: > Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like > users to have the option to see their passwords. > In iOS, I can do something like [textField setSecureTextEntry:YES]; > > I found [secureTextField setEchoBullets] but that's not what I want. No. You'll have to swap between instances of NSTextField and NSSecureTextField, keeping the two controls' stringValues in sync. --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: Managing image loading
Thank you Jens. I have found the proper way to manage that. When the user imports a new image, I quickly copy the image to a temporary folder, then I add this latest file reference to the document¹s NSFileWrapper. I just create the file¹s fileWrapper using its URL, so I do not read its content and create the fileWrapper by the NSData. When the users saves the document, automatically the filesWrappers get written to the disk, within the document filePackage. And when I close the document, I remove the temp folder. That¹s fine. I had to scratch my head at managing the undo, but I found a solution here too. When the user undo the import of an image, if the images has been never saved, so it is still within the temporary folder, I just remove the image file reference from the fileWrapper. Instead, if the image has already been saved, so it is within the file package, I copy its file to the temporary folder and remove its reference from the fileWrapper. So when the user saves the doc, the image file get removed from the doc filePackage. And if the user invokes the undo, I add the temp image file to the fileWrapper. It sounds complicated but it works well. Why do I use a temporary folder? Because if the user imports an image file then he tries to delete the original image file, the OS tells him that he can¹t delete that file in use. That could be annoying. Why don¹t I add the file¹s NSData to the fileWrapper but I add just its URL reference? Because I don¹t really know whether the fileWrapper uses the disk or keeps the NSData in memory. So in case of a 1GB file I do not engulf the app. I hope I have designed a good architecture. Regards -- Leonardo Da: Jens Alfke Data: Tue, 4 Feb 2014 11:47:35 -0800 A: Leonardo Cc: Oggetto: Re: Managing image loading On Feb 4, 2014, at 9:03 AM, Leonardo wrote: > - When the user imports a new image, I add its NSData to the NSFileWrapper >[docFileWrapper addRegularFileWithContents:imgData >preferredFilename:@"image.png"]; > and retain the NSImage. So I can draw the NSImage at any time. You don't need an NSFileWrapper for that. I would just use NSFileManager to copy the file, and NSData methods to read/write the file. I have no idea whether NSFileWrapper caches the file contents in memory or not. Jens ___ 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
Getting QuickLook to work with NSDocument
I'm trying to get QuickLook preview to work with NSDocument - much as in the
QuickLookDownloader example provided by Apple.
I thought I had it all set up correctly -
#import
@interface Document : NSDocument
{
QLPreviewPanel* previewPanel;
}
Something is clearly amiss though - because acceptsPreviewPanelControl is never
called. Does anyone know of any really simple, dumbass examples (simpler even
than QuickLookDownloader) that might help me untangle this conundrum?
___
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
