> Pragmatically, you can set a repeating NSTimer of (say) 0.1 secs and poll the
> panel visibility. The processing load in minuscule, and the UI lag is
> basically undetectable.
That's a bad assumption. Short, periodic timers can muck with the system's
power management, ultimately wasting powe
> One warning about extremely large views is that at some point you will run
> into floating-point rounding errors, since AppKit and CoreGraphics coords are
> 32-bit floats and have only 24 bits of precision. Still, that should get you
> to millions of pixels before the coords stop being pixel-a
> Does NSBezierPath do decimation as well as interpolation? I didn't find it in
> the Class Reference.
It does whatever it needs to do in order to achieve "great" results, where
"great" is in practical terms something like "an order of magnitude finer than
pixel resolution".
Last I checked, it
> - (void)saveToURL:(NSURL *)url
> ofType:(NSString *)typeName
> forSaveOperation:(NSSaveOperationType)saveOperation
> completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
> if (saveOperation == NSAutosaveInPlaceOperation) {
> if ([[[NSOperationQueue mainQueue] oper
> Looking back at code I wrote years ago, I see that I usually did things like
>@try {
>someObject = [NSKeyedUnarchiver unarchiveObjectWithData:someData];
>} @catch (id exception) {
>someObject = nil;// or some other reasonable default state
>// mark someData as
> The fact that these methods throw exceptions if their input data cannot be
> processed is very uncharacteristic of the Cocoa frameworks.
Now it is. Back when NSCoding et al were written, possibly not. Opinions on
the use of exceptions vs other methods have waxed and waned over the years.
O
> Oh, I don't know how I missed this, but there's a very convenient
> -[NSArray pathsMatchingExtensions:] method already declared in
> NSPathUtilities.h:
> http://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/Classes/NSArray_Class/NSArray.html#//apple_ref/doc/uid/2137
>> Another thing to mention - we run this code during app launch, so we didn't
>> see it in fs_usage, which requires that the process it's peeking at is
>> running already. I'm not sure if there is a way to observe file system stuff
>> during launch - if anyone knows, please let me know!
sudo f
