Re: Memory leak in Apple's image handling frameworks ?

[Sandy McGuffog via Cocoa-dev]

Yet another possible issue is that Apple’s frameworks tend to like to hold onto 
and reuse objects like CALayers. As a result they also hold onto the contents 
for much longer than you might think. I would at least try imgLayer.contents = 
nil as soon as you’re sure the layer won’t be displayed again.

Regards,

Sandy

> On May 1, 2023, at 3:46 AM, Christopher Snowhill via Cocoa-dev 
>  wrote:
> 
> Another possibility is insufficient use of autorelease pools. Even if you are 
> freeing your Objective C objects, if you do not exit the nearest autorelease 
> pool block, they will simply accumulate in the heap. Leak tools will not 
> consider these to be "leaked" memory.
> 
>> On Apr 30, 2023, at 4:41 PM, Alex Zavatone via Cocoa-dev 
>>  wrote:
>> 
>> What I tested was if it matched the Xcode memory pie chart across several 
>> apps.
>> 
>> I can’t remember what results I got with terminal leaks or heap commands.
>> 
>> Add it to one of your programs and give it a shot!  Now I’m interested.
>> 
>> Cheers,
>> Alex Zavatone
>> 
>>> On Apr 30, 2023, at 1:33 PM, Rob Petrovec  wrote:
>>> 
>>> Curious, Alex, what does this memoryFootprint function show that running 
>>> ‘footprint’ or ‘heap’ in Terminal doesn’t?
>>> 
>>> —Rob
>>> 
>>> 
> On Apr 30, 2023, at 8:12 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
 
 Memory used query method for iOS.
 
 https://stackoverflow.com/a/57315975/1058199
 
 //  Created by Alex Zavatone on 8/1/19.
 //
 
 class Memory: NSObject {
 
 // From Quinn the Eskimo at Apple.
 // https://forums.developer.apple.com/thread/105088#357415
 
 class func memoryFootprint() -> Float? {
 // The `TASK_VM_INFO_COUNT` and `TASK_VM_INFO_REV1_COUNT` macros are 
 too
 // complex for the Swift C importer, so we have to define them 
 ourselves.
 let TASK_VM_INFO_COUNT = 
 mach_msg_type_number_t(MemoryLayout.size / 
 MemoryLayout.size)
 let TASK_VM_INFO_REV1_COUNT = 
 mach_msg_type_number_t(MemoryLayout.offset(of: 
 \task_vm_info_data_t.min_address)! / MemoryLayout.size)
 var info = task_vm_info_data_t()
 var count = TASK_VM_INFO_COUNT
 let kr = withUnsafeMutablePointer(to: &info) { infoPtr in
 infoPtr.withMemoryRebound(to: integer_t.self, capacity: 
 Int(count)) { intPtr in
 task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), 
 intPtr, &count)
 }
 }
 guard
 kr == KERN_SUCCESS,
 count >= TASK_VM_INFO_REV1_COUNT
 else { return nil }
 
 let usedBytes = Float(info.phys_footprint)
 return usedBytes
 }
 
 class func formattedMemoryFootprint() -> String
 {
 let usedBytes: UInt64? = UInt64(self.memoryFootprint() ?? 0)
 let usedMB = Double(usedBytes ?? 0) / 1024 / 1024
 let usedMBAsString: String = "\(usedMB)MB"
 return usedMBAsString
  }
 }
 Enjoy
 
 
 
> On Apr 30, 2023, at 9:05 AM, Alex Zavatone  wrote:
> 
> Use the memory graph debugger, not Instruments.  
> 
> I also have a method published on StackOverflow that lets you check on 
> and print out the amount of memory used.  It is for iOS.
> 
> As for abandoned memory, that also could be the case.  An object in 
> memory with no pointer to it.
> 
> If you want, we could do a video meeting and I could guide you through 
> it. 
> 
> Will reply with the memory querying function.
> 
> Cheers,
> Alex Zavatone
> 
> Sent from my iPhone
> 
>> On Apr 29, 2023, at 11:15 PM, Rob Petrovec via Cocoa-dev 
>>  wrote:
>> 
>> This sounds like Abandoned Memory, not a leak.  Abandoned memory is a 
>> retain cycle somewhere.  Best/easiest way to find those is with a 
>> memgraph.  Click the little sideways V icon in Xcode’s debugger when the 
>> problem is reproducing.
>> 
>> 
>> 
>> Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the problem is 
>> reproducing and open the resulting .memgraph file in your home 
>> directory.  Bonus points is enabling MallocStackLogging in the Xcode 
>> Project -> Edit Scheme -> Run -> Diagnostics and check Malloc Stack 
>> Logging and switch to All Allocations And Free History. This will show 
>> backtraces for where an object is created in the memgraph and other 
>> useful info.
>> 
>> Leaks show up as little yellow caution signs and abandoned memory 
>> sometimes have purple caution signs. Either way, look for an abnormally 
>> high number of objects and see if they point back to your image.  Thats 
>> likely where your memory is being consumed.
>> 
>>> CGImageSourceCreateWithURL() for loading, CALayer for displaying.
>> Just a thought since you didn’t mention it: are you releasing the 
>> CGImageSource object too?
>> 
>>

Re: Sandboxing question regarding ~/Pictures

[Sandy McGuffog via Cocoa-dev]

The sandbox is an enigma wrapped in a mystery. But you might need to look at 
the the com.apple.security.assets.pictures.read-write entitlement


> On Sep 27, 2021, at 3:30 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I guess i still haven't understood something about sandboxing or entitlements.
> 
> I am trying to access the user's ~/Pictures folder, and also create a 
> security-scoped bookmark (SSB) for that folder.
> 
> Under the target's Signing & capabilities section, File Access Type, I have 
> set "Pictures Folder" to read/write.
> 
> Getting the path using this
>NSURL * pic_dir = [ [NSFileManager defaultManager] URLForDirectory: 
> NSPicturesDirectory
>  inDomain: 
> NSUserDomainMask
> appropriateForURL: 
> nil create: NO error: &err];
> 
> and doing a spotlight search over the folder works just fine.
> 
> However, creating a SSB for pic_dir does not work.
> 
> I am trying to create it like this:
> 
>NSData * dir_bookmark = [dir bookmarkDataWithOptions: 
> NSURLBookmarkCreationWithSecurityScope
>   includingResourceValuesForKeys: nil
>relativeToURL: nil
>error: &systemError];
> 
> But I get this error:
> 
> Error Domain=NSCocoaErrorDomain Code=256 "Could not open() the item" 
> UserInfo={NSURL=file:///Users/zach/Library/Containers/de.zach.ArtSaverApp/Data/Pictures/,
>  NSDebugDescription=Could not open() the item}!
> 
> 
> All of this is happening under macOS 11.5.2 .
> 
> Any insights will be highly appreciated.
> G.
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: How to refund a customer on mac app store?

[Sandy McGuffog via Cocoa-dev]

You can’t. The customer needs to contact Apple directly.

> On Oct 25, 2020, at 4:30 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Is it possible to give a refund to a customer who has bought my app on the 
> Mac App Store?
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: device-pixel-exact bitmap rendering

[Sandy McGuffog]

Having been down this rat hole once or twice for my apps, I can only tell you 
my understanding. Which may or may not have any bearing on reality:

If you select a “non-native" display mode, then the display/display driver are 
responsible for the conversion from the selected resolution to native 
resolution. This will be invisible to your app. In other words, at the NSView 
level, the backing store (if it’s a pixel backing store) will be at selected 
resolution, not native resolution. This has nothing (or at least not much) to 
do with retina mode, which really only refers to the mapping between points and 
pixels. That is visible to your app. A pixel level backing store for a retina 
display will always be at full res.

You may possibly be able to “see” native rather than “selected resolution” with 
e.g., an OpenGL view or similar - I don’t know. I gave up trying to use the low 
level interface years ago. But I don’t think you can with the conventional 
Cocoa display stack you are currently using.

Sandy

> On Dec 19, 2016, at 12:52 AM, Kurt Bigler  wrote:
> 
> On 12/18/16 12:33:53 PM, Ken Thomases wrote:
>> On Dec 18, 2016, at 2:15 AM, Kurt Bigler  wrote:
>>> 
>>> But if in Displays I set the resolution to 1920x1200 "More Space", then I 
>>> can't get the backing store to match the 2880x1800 physical display 
>>> resolution.  I need my NSView's backing store scale factor to be 1.5, but 
>>> the doc says this is impossible.  As things are currently coded, my image 
>>> gets smaller, and I get weird artifacts in high-contrast high-resolution 
>>> information.  Presumably the backing store resolution is 3840x2400.
>> 
>> What exactly did you try?  For example, what size did you make your image 
>> for this scenario?  How did you draw it?  Did you try drawing a 2880x1800 
>> pixel image to a 1920x1200 point rectangle (or some appropriate fraction of 
>> those sizes) using CGContextDrawImage()?
> 
> I tried various possibilities at one time or another, and eventually 
> discovered as a result that it was a complete mess if the destination was not 
> targeted with awareness of the scale factor of the backing layer, so that the 
> rectangle  that would result in the backing layer (not explicit in my code) 
> matches 1:1 with the bitmap I'm drawing using CGContextDrawImage.
> 
> So basically in the retina case that works, my source rectangle is 2x, and 
> that is the basis of calculating the pixels for the CGImage.  But the 
> destination rectangle for CGContextDrawImage is in view coordinates which are 
> 1x, yet of course behind the scenes that destination becomes 2x for the 
> actual image copy to the backing store which is at 2x.  So a 100x100 view 
> area gets a 200x200 image.
> 
> Still the essentials as I see it are the fact that it works perfectly when 
> the backing store resolution and scale factor match the device, and that the 
> OS seems to interfere with the possibility of that matching except when the 
> ratio is 2 to 1.  And the next best (next-least-distorted) result when the 
> backing store doesn't match the device is still to have the source image 
> match the backing store.
> 
> So I'm back to hoping it is a simple question, i.e. for Apple.
> 
>> You mention CALayer, albeit mostly in the context of something you don't 
>> know much about.  Is your view layer-backed?
> 
> You tell me.  :)   No I didn't do anything to try to arrange that.  But 
> clearly there is some default backing store.  What is it?  Some doc says 
> there is a default CALayer that is in some way trivial but it is not 
> explained in what situation that default applies.
> 
> Does it make any difference if you make it so by setting wantsLayer (either 
> in code or in IB)?
> 
> I don't want that off-hand because it gets me into the things I don't yet 
> understand.  :)   I'm willing to do it if it is necessary but don't get 
> excited about it if I can just tell the backing layer to have the desired 
> resolution although the docs claim it doesn't, and the question is whether 
> that means can't.
> 
> The mere name "Core Animation" suggests things I have no interest in since I 
> have only a static image, yet of course names can be misleading.  It's just 
> that the doc constantly rubs in that Core Animation is for animation, and the 
> other layer example I saw was for a video layer.
> 
> So I'm still thinking it ought to be a simple question and hope first for the 
> simple answer even if it is that I must create my own backing layer, and even 
> that CALayer is appropriate when I have no need for animation.  If that's 
> what's needed that's what I do, and I can learn all about it in the coming 
> weeks, but want to hear clearly that I need to get into that particular 
> wrestle to solve the simple problem.
> 
>> Regards,
>> Ken
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact th

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

[Sandy McGuffog]

Based on that, where you’re losing memory is to bitmapped backed CALayers that 
aren’t being released. Depending on the size of the bitmap, they can be big - 
MBs each. They are being allocated in the Kernel, so aren’t showing in 
instruments. Why they aren’t being released, I couldn’t say. Maybe a retain 
loop, maybe an animation that never finishes, etc, etc. But I’d starting 
looking (a) by removing any Core animation you can, and (b) I’d look at any 
NSWindows/NSViews/NSControllers that aren’t being released when you close all 
visible windows.

Sandy

> On Sep 17, 2015, at 1:13 PM, Jean Suisse  wrote:
> 
> 
>> On 16 sept. 2015, at 18:58, Quincey Morris 
>>  wrote:
>> 
>> On Sep 16, 2015, at 04:00 , Jean Suisse  wrote:
>>> 
>>> Does anyone know what to try / measure / observe to get more clues?
>> 
>> It seems you’re “losing” free memory fast enough for this to be visible 
>> using heap generations in Instruments’ Allocations. The difficulty with 
>> marking generations is that you’d really like the app (at least its 
>> memory-wasting activities) to go quiescent long enough and often enough to 
>> let you set marks when it’s not doing anything.
>> 
>> You could do this by changing your timer to fire (say) every minute instead 
>> of every second. In Instruments, wait until you see a UI update, then wait 
>> about 30 more seconds, then mark the generation. Do this several times, and 
>> you should be able find out exactly what’s being leaked. (“Why” might be 
>> harder.)
> 
> 
> I did that. All I see is that the memory is taken (not leaked) after 
> __CFRunLoopDoObservers and CA::Transaction::commit().
> 
> Bytes UsedCount   Symbol Name
>  30.61 MB  97.0%  11645   start
>  30.61 MB  97.0%  11645   main
>  30.61 MB  97.0%  11645NSApplicationMain
>  30.61 MB  97.0%  11645 -[NSApplication run]
>  30.59 MB  96.9%  11644  -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:]
>  30.59 MB  96.9%  11643   _DPSNextEvent
>  30.59 MB  96.9%  11643
> _BlockUntilNextEventMatchingListInModeWithFilter
>  30.59 MB  96.9%  11643 ReceiveNextEventCommon
>  30.59 MB  96.9%  11643  RunCurrentEventLoopInMode
>  30.59 MB  96.9%  11643   CFRunLoopRunSpecific
>  29.27 MB  92.7%  161  __CFRunLoopDoObservers
>  29.27 MB  92.7%  161   
> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
>  29.27 MB  92.7%  161
> CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*)
>  28.93 MB  91.6%  139 CA::Transaction::commit()
>  28.93 MB  91.6%  139  
> CA::Context::commit_transaction(CA::Transaction*)
>  28.92 MB  91.6%  22
> CA::Layer::layout_and_display_if_needed(CA::Transaction*)
>  28.92 MB  91.6%  22 
> CA::Layer::display_if_needed(CA::Transaction*)
>  28.92 MB  91.6%  22  -[_NSViewBackingLayer display]
>  28.92 MB  91.6%  22   _NSBackingLayerDisplay
>  28.92 MB  91.6%  22CA::Layer::display_()
>  28.92 MB  91.6%  22 x_blame_allocations
>  28.92 MB  91.6%  22  
> ___ZN2CA5Layer8display_Ev_block_invoke
>  28.92 MB  91.6%  22   CABackingStoreUpdate_
>  28.76 MB  91.1%  2 
> CA::Render::Shmem::new_bitmap(unsigned int, unsigned int, unsigned int, 
> unsigned int)
>  28.76 MB  91.1%  2  
> CA::Render::Shmem::new_shmem(unsigned long)
>  28.76 MB  91.1%  2   vm_allocate
>  28.76 MB  91.1%  2mach_vm_allocate
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: Thread-safe atomic property for array

[Sandy McGuffog]

Well, in my experience, in multithreaded code, if you can’t guarantee that 
something won’t happen, sooner or later it will, so you better code around it. 
Murphy’s law is particularly strong as regards multithreading :)

> On Aug 15, 2015, at 2:36 PM, Mike Abdullah  wrote:
> 
> 
>> On 15 Aug 2015, at 13:21, Sandy McGuffog  wrote:
>> 
>> What guarantees that the current autorelease cycle doesn’t end in the middle 
>> of this code?
> 
> If it does end in the middle of this code, that’s something the author of the 
> code is doing specially and must deal with the consequences by themselves. 
> Trying to protect against that in general is futile.
>> 
>> Actually, as I think about it, technically, the [[hostObject myArray] 
>> retain] should be wrapped in some kind of lock mechanism itself to make it 
>> atomic….
> 
> Go back and read the question. The OP explicitly states that this is an 
> atomic property, and they don’t care if the results are a bit out of date. No 
> extra locking required.
> 


___

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: Thread-safe atomic property for array

[Sandy McGuffog]

What guarantees that the current autorelease cycle doesn’t end in the middle of 
this code?

Actually, as I think about it, technically, the [[hostObject myArray] retain] 
should be wrapped in some kind of lock mechanism itself to make it atomic….


> On Aug 15, 2015, at 2:10 PM, Mike Abdullah  wrote:
> 
> 
>> On 15 Aug 2015, at 13:07, Sandy McGuffog  wrote:
>> 
>> 
>>> On Aug 15, 2015, at 1:14 PM, Mike Abdullah  wrote:
>>> 
>>> NSArray *array = [hostObject myArray];
>>> // run your checks, etc.
>>> NSString *someString = [array objectAtIndex:2];
>> 
>> Just to be safe:
>> 
>> NSArray *array = [[hostObject myArray] retain];
>> // run your checks, etc.
>> NSString *someString = [array objectAtIndex:2];
>> [array release];
>> 
>> Or whatever other way of ensuring the array isn’t dealloced out from under 
>> you, depending on how you’re doing memory management
> 
> No need. The OP has stated myArray is an atomic property. It’s guaranteed not 
> to go away until the end of the current autorelease pool.
> 
> If the above code did actually add some protection, it would mean the first 
> line of code had a race condition in it where you might not be able to retain 
> in time. You’d just be hiding the problem and making it less likely, rather 
> than actually fixing 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

Re: Thread-safe atomic property for array

[Sandy McGuffog]

> On Aug 15, 2015, at 1:14 PM, Mike Abdullah  wrote:
> 
> NSArray *array = [hostObject myArray];
> // run your checks, etc.
> NSString *someString = [array objectAtIndex:2];

Just to be safe:

NSArray *array = [[hostObject myArray] retain];
// run your checks, etc.
NSString *someString = [array objectAtIndex:2];
[array release];

Or whatever other way of ensuring the array isn’t dealloced out from under you, 
depending on how you’re doing memory management
___

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: App crashes on launch when using Developer ID-signed Mac Installer Package

[Sandy McGuffog]

Alex,

Don’t know….in my case, this was OS X

Sandy

> On Feb 11, 2015, at 8:25 PM, Alex Zavatone  wrote:
> 
> Any idea if this only affects OS X or does it also affect iOS?
> 
> Sent from my iPad. Please pardon typos.
> 
> On Feb 11, 2015, at 12:55 PM, Sandy McGuffog  wrote:
> 
>> Brad,
>> 
>> Yes, Xcode 6 breaks what used to be valid signing workflows under previous 
>> versions. Unfortunately, Apple’s documentation hasn’t caught up, and most of 
>> DTS is clueless on this subject. It took me literally months to get a useful 
>> answer. This BTW is not a bug, it is apparently as a result of Apple 
>> deliberately tightening up signing requirements.
>> 
>> In short, the only supported workflow now is “team based signing”. Apple is 
>> quite vague about what that really means, but in my case it involve setting 
>> Code Signing Identity to “Developer”, and Provisioning Profile to 
>> “Automatic”. Trying to override these settings with e.g., a specific 
>> profile, results in bad things happening.
>> 
>> Sandy
>> 
>> 
>>> On Feb 11, 2015, at 7:05 PM, Bradley O'Hearne  
>>> wrote:
>>> 
>>> Hello, 
>>> 
>>> I am using Xcode 6.1.1 on OS X Yosemite and have exported an archive as a 
>>> Mac Installer Package using a Developer ID to sign it. The installer is 
>>> created successfully, and when run, the installer executes the installation 
>>> successfully. But when I attempt to launch the app, it crashes immediately, 
>>> with the following in the crash dump: 
>>> 
>>> Exception Type:EXC_CRASH (Code Signature Invalid)
>>> Exception Codes:   0x, 0x
>>> 
>>> The problem is somehow with signing, though build settings in Xcode all 
>>> follow the documented approach to code signing using the proper Mac 
>>> Developer Program certificates. I have no errors or warnings when building 
>>> the app. I have no errors or warnings or problems launching and running the 
>>> app in the debugger. I also can export the same archive as a Developer 
>>> ID-signed Application and it exports, launches, and runs just fine. 
>>> Additionally, this is not something new I'm doing -- in previous 
>>> development cycles (and earlier in this one) I was able to successfully 
>>> export as a Mac Installer Package and run fine -- albeit that was on 
>>> earlier versions of Xcode (and possibly OS X too). 
>>> 
>>> In various other Internet-y places, I have found references to others 
>>> having this same problem recently, but none of those had any resolution. A 
>>> couple of posters commented that even after several weeks with 
>>> communicating with Apple DTS they still hadn't been given or were able to 
>>> find a resolution. So I am appealing to the community on the following 
>>> points: 
>>> 
>>> Has anyone who has encountered this found a resolution to the problem? 
>>> Can anyone confirm this as a legitimate Xcode bug? 
>>> Any other suggestions to get around this? (Please note -- for reasons out 
>>> of my control, this app has to be distributed as a Developer ID-signed Mac 
>>> Installer Package -- we cannot distribute at this time through the Mac App 
>>> Store. Perhaps down the road, but not at this time). 
>>> 
>>> Your help is appreciated. This is a direct show-stopper for us being able 
>>> to ship our app to production. 
>>> 
>>> Thanks, 
>>> 
>>> Brad
>>> ___
>>> 
>>> 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/mcguffogl%40gmail.com
>>> 
>>> This email sent to mcguff...@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/zav%40mac.com
>> 
>> This email sent to z...@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: App crashes on launch when using Developer ID-signed Mac Installer Package

[Sandy McGuffog]

Brad,

Yes, Xcode 6 breaks what used to be valid signing workflows under previous 
versions. Unfortunately, Apple’s documentation hasn’t caught up, and most of 
DTS is clueless on this subject. It took me literally months to get a useful 
answer. This BTW is not a bug, it is apparently as a result of Apple 
deliberately tightening up signing requirements.

In short, the only supported workflow now is “team based signing”. Apple is 
quite vague about what that really means, but in my case it involve setting 
Code Signing Identity to “Developer”, and Provisioning Profile to “Automatic”. 
Trying to override these settings with e.g., a specific profile, results in bad 
things happening.

Sandy


> On Feb 11, 2015, at 7:05 PM, Bradley O'Hearne  
> wrote:
> 
> Hello, 
> 
> I am using Xcode 6.1.1 on OS X Yosemite and have exported an archive as a Mac 
> Installer Package using a Developer ID to sign it. The installer is created 
> successfully, and when run, the installer executes the installation 
> successfully. But when I attempt to launch the app, it crashes immediately, 
> with the following in the crash dump: 
> 
> Exception Type:EXC_CRASH (Code Signature Invalid)
> Exception Codes:   0x, 0x
> 
> The problem is somehow with signing, though build settings in Xcode all 
> follow the documented approach to code signing using the proper Mac Developer 
> Program certificates. I have no errors or warnings when building the app. I 
> have no errors or warnings or problems launching and running the app in the 
> debugger. I also can export the same archive as a Developer ID-signed 
> Application and it exports, launches, and runs just fine. Additionally, this 
> is not something new I'm doing -- in previous development cycles (and earlier 
> in this one) I was able to successfully export as a Mac Installer Package and 
> run fine -- albeit that was on earlier versions of Xcode (and possibly OS X 
> too). 
> 
> In various other Internet-y places, I have found references to others having 
> this same problem recently, but none of those had any resolution. A couple of 
> posters commented that even after several weeks with communicating with Apple 
> DTS they still hadn't been given or were able to find a resolution. So I am 
> appealing to the community on the following points: 
> 
> Has anyone who has encountered this found a resolution to the problem? 
> Can anyone confirm this as a legitimate Xcode bug? 
> Any other suggestions to get around this? (Please note -- for reasons out of 
> my control, this app has to be distributed as a Developer ID-signed Mac 
> Installer Package -- we cannot distribute at this time through the Mac App 
> Store. Perhaps down the road, but not at this time). 
> 
> Your help is appreciated. This is a direct show-stopper for us being able to 
> ship our app to production. 
> 
> Thanks, 
> 
> Brad
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: dispatch_sync(dispatch_get_main_queue() UI weirdness

[Sandy McGuffog]

Difficult to know exactly what's happening in your situation, but I’d be 
inclined to try something like:

dispatch_time_t duration = dispatch_walltime(DISPATCH_TIME_NOW, 
offset_nsec);

dispatch_after(duration, dispatch_get_main_queue(), ^{

});

where offset_nsec is long enough to allow the app to complete it’s start-up 
process

Sandy

On Sep 5, 2014, at 10:31 PM, Jonathan Guy  wrote:

> I’m using a third party c library that requires registering a callback which 
> gets called if the operation encounters an invalid server certificate (should 
> i accept or reject the cert). The callback needs to return yes or no, which I 
> need to get via a UI prompt so the prompt needs to block so I can return 
> appropriately from the callback. So my initial thoughts are “present the cert 
> in a modal window”. So I put the cert in a SFCertificateView in a scroll view 
> and present it in a modal window but it could not be scrolled up and down 
> which was the initial problem. I also tried the SFCertificatePanel with the 
> same problem. After testing I found I couldn’t scroll any scroll view so I 
> knocked up that small bit of code to show as an example. I tried using 
> performSelectorOnMainThread and waiting until completion and this funnily 
> enough works fine in terms of absolutely no UI weirdness but I can’t get a 
> return value from that plus there were other issues.
> There could be any number of operations running concurrently and any one 
> could require validation at any time.
> 
> The callback is basically structured like this
> 
>   __block BOOL accept;
>   
>   if ([NSThread isMainThread]) {
>   accept = [[Controller sharedController] shouldIAccept:certInfo];
>   }
>   else {
>   dispatch_sync(dispatch_get_main_queue(), ^{
>   accept = [[Controller sharedController] 
> shouldIAccept:certInfo];
>   // This is where UI starts playing up when the 
> controller shows the cert
>   });
>   }
>   
>   return accept;
> 
> So the shouldIAccept method needs to block hence runModal. I also just threw 
> the window up and created my own modal loop but same problem.
> 
> On 5 Sep 2014, at 19:59, Jens Alfke  wrote:
> 
>> 
>>> On Sep 5, 2014, at 11:44 AM, Jonathan Guy  wrote:
>>> 
>>> when the NSOpenPanel opens all kinds of weirdness is going on. The scroll 
>>> views scroll very erratically if at all and the directories don't list 
>>> properly. 
>> 
>> Well, you've blocked one of the threads that services the global dispatch 
>> queue — it's stuck in a dispatch_sync call that won't return until the user 
>> dismisses the open panel. I don't know exactly what kinds of problems 
>> blocking the queue will cause, but it's definitely not a good idea. (The 
>> problems you report sound more severe than what I would guess would happen, 
>> but I definitely don't know how concurrent dispatch queues are implemented.)
>> 
>> You should rewrite your code to use dispatch_async instead. Then when the 
>> modal session completes, call back to the global dispatch queue to finish 
>> running your code.
>> 
>> (And the whole scenario you're giving sounds like bad UI design — your code 
>> shouldn't suddenly pop up a modal panel just because you "need a file from 
>> the user". The user should be in control of tasks like opening files. But 
>> you may have created an unrealistic scenario just as an example…)
>> 
>> —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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: document inexplicably becomes locked and fails to save under sandboxing

[Sandy McGuffog]

I don’t know whether this is relevant to your issue, but for what it’s worth, 
(a) I have had a problem with OS X mysteriously locking files as result of the 
file being set to "user immutable”, and (b) I know that the autosave 
functionality in NSDocument interacts with the immutable setting. 

In my case, the solution was just to do:
[path setResourceValue:[NSNumber numberWithBool:NO] 
forKey:NSURLIsUserImmutableKey error:nil];

Sandy


On Jun 12, 2014, at 10:11 PM, Martin Wierschin  wrote:

>> I need to do some more testing, but I may have a workaround for my problem. 
>> Instead of opening the document via NSDocumentController, ask NSWorkspace to 
>> open the file in my app instead
> 
> I spoke too soon. Reopening the document via NSWorkspace also has the same 
> problem: the sandbox will eventually show the document as locked and/or deny 
> the user access to the file.
> 
> Filed as radar://17291335 
> 
> This is a huge problem for our app, so if anyone has any other tips, I'd be 
> very appreciative.
> 
> Thank you,
> ~Martin Wierschin
> 
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: EXC_BAD_ACCESS in NSData

[Sandy McGuffog]

Well,

I find your code to be a bit confusing, but I’d say that both of those are 
wrong. I think that what you need is:

  unsigned char* databuffer = (unsigned char*)malloc(datasize);
  [datastream getBytes:databuffer range:NSMakeRange(positionCounter, 
datasize)]; // Packet content


On May 26, 2014, at 3:44 PM, Pax <45rpmli...@googlemail.com> wrote:

> Apologies - the obvious important detail, and I missed it out entirely.  I 
> have tried both of the following with the same result:
> 
>   unsigned char* databuffer = (unsigned char*)malloc(datasize);
>   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content
> 
> and 
> 
>   unsigned char* bytes;
>   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
> // Packet content
> 
> Either way, I get the same result.
> 
> 
> 
> On 26 May 2014, at 14:16, Uli Kusterer  wrote:
> 
>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>>> This is my snippet of code:
>>>  [datastream getBytes:&bytes 
>>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>>  positionCounter+= datasize;
>> 
>> What is bytes declared as, and what do you initialize it to?
>> 
>> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: Image without profile gets an sRGB profile on Mavericks

[Sandy McGuffog]

Untagged images are a free-for-all - any app or framework can assume whatever 
it wants for a color space with them, so there’s no “wrongly” about what 
Mavericks does. It’s just different to previous versions. 

So far as I am aware, Apple is (strongly) discouraging the use of Device RGB, 
for the good reason that using it leads to inconsistent results. 

Sandy


On Mar 23, 2014, at 8:14 PM, Leonardo  wrote:

> I create a jpg RGB image with Photoshop "without" any icc profile.
> I import it in my app.
> 
> NSBitmapImageRep*srcRep = [NSBitmapImageRep imageRepWithData:imageData];
> NSLog(@"profileName %@", srcRep.colorSpace.localizedName);
> 
> On OS X 10.8.5 I properly get "Device RGB".
> On Mavericks 10.9.2 I wrongly get "sRGB IEC61966-2.1".
> 
> Therefore I can't understand whether the image:
> 1. has no profile then I have to assign a profile chosen by my user.
> 2. has its own profile then I do not touch it.
> 
> I even tried CGColorSpaceCopyName. Same result.
> Did Apple changed its mind on Mavericks giving a profile to all the orphans,
> or am I missing some step?
> 
> 
> Regards
> -- Leonardo
> 
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: exporting image files to disk using CGImageDestination

[Sandy McGuffog]

You should not be seeing worse image quality for TIFF unless very different 
options are being used in each case. Can you tell what about the image quality 
is worse?

Sandy


On Feb 24, 2014, at 7:48 PM, Kevin Meaney  wrote:

> On 24 Feb 2014, at 17:21, Mike Abdullah  wrote:
> 
>> On 24 Feb 2014, at 17:00, Kevin Meaney  wrote:
>>> I've written a command line tool that takes an image file (when testing I'm 
>>> using JPEG files) and applies a custom CIFilter (a naive chroma key filter 
>>> I've written) and saves a file to disk. Sampling the command line tool when 
>>> processing files shows it is spending 90% of its time writing the png file 
>>> of which most of this time is spent in a function called deflate in libz. 
>>> The final file quality is good. I'm using CGImageDestination to export the 
>>> file with default settings.
>> I’m a little unclear here. Are you saying the process appears to much slower 
>> than you can reasonably expect? Or simply that you’d like to find a way to 
>> make it go faster? (something which may well not be very possible)
>> 
> 
> I'd like one of two things, either getting the same quality exporting as TIFF 
> as I do with PNG since exporting as tiff is more than 5 times faster, or that 
> saving as PNG is faster. I suppose I don't understand when TIFF saving as 
> uncompressed is meant to be lossless why is the image quality so much worse 
> than saving as PNG.
> 
> The ImageIO documentation relating to the dictionary properties when setting 
> values to the CGImageDestination object, or when adding an image to the 
> destination object are not really clear as to where to set which is 
> appropriate. Secondly the description of the keys for the dictionary are not 
> particularly helpful. Trying to work out what settings my work to achieve my 
> goal is confusing and perhaps it is impossible. Both the speed difference 
> between TIFF and PNG, and the quality difference surprised me.
> 
> Kevin
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: Writing a custom core image filter part 2

[Sandy McGuffog]

In the return statement, did you not perhaps mean inputColorProps rather than 
inputColor?

Sandy

On Feb 24, 2014, at 12:10 AM, Kevin Meaney  wrote:

> inputColor,


___

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: Sandbox and CIKernel

[Sandy McGuffog]

I have used CIKernels in a sandboxed app. Different kernel :)

Sandy

On Nov 22, 2013, at 5:56 PM, Gordon Apple  wrote:

> I¹m a little confused as to whether or not one can use a CIKernel in a
> samdboxed app.  Custom filters often require this and WWDC is full of
> examples using such. Sandbox guides say no kernel extensions.  Is CIKernel a
> special case? What¹s the story on this?
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: IOS floating point performance

[Sandy McGuffog]

Be careful using that code as a test; a good optimizing compiler could pick up 
that sin is a library function without side effects, and no result is saved, 
and optimize that loop to two calls to adjustValueRadians. 

Sandy

On Aug 8, 2013, at 8:17 PM, Thomas Wetmore  wrote:

> David,
> 
> Those are lightening speeds. So I agree with you wholeheartedly -- there is 
> no sense in working on a custom table-driven approach. The current approach 
> must already be table-based with speeds like that.
> 
> Tom Wetmore
> 
> 
> On Aug 8, 2013, at 1:26 PM, David Rowland  wrote:
> 
>> I wrote an app that calculates the positions of Sun and Moon and other 
>> information as well. The heart of the Moon calculation is this. I added a 
>> loop around it and called a stopwatch at the beginning and end.
>> 
>>  startTime();
>>  for (int jj = 0; jj<100;++jj)
>>  {
>>  //in radians
>>  double lambda = 3.81040282295402 + 8399.70910754626 * T
>>  + 0.109781209950443 * sin(adjustValueRadians(2.35619449019234 + 
>> 8328.69146829639 * T))
>>  - 0.022165681500328 * sin(adjustValueRadians(4.5256387504213 - 
>> 7214.06294691607 * T))
>> 
>> One hundred times through this loop, on my iPhone 5, took about 0.0028 
>> seconds. Two hundred times took about 0.0056 sec.
>> 
>> I infer that one pass takes about 0.28 seconds, or 28.0 microseconds.
>> 
>> The functions are probably very carefully written and could not be improved 
>> by table lookups, vector libraries, etc. That is barking up the wrong tree. 
>> 
>> David
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: Detect a Retina display

[Sandy McGuffog]

What you need is to set base SDK to most recent (10.8), and set deployment 
target to 10.6

Sandy

On Jun 20, 2013, at 5:11 PM, Thierry Cantet  wrote:

> Hello Richard,
> 
> I have tried your solution, however it does not work.
> 
> I have these messages when I try to build with the base SDK set to 10.6 :
>(Warning)Instance method '-convertRectToBacking:' not found (return type 
> defaults to 'id')
>(Error)No viable conversion from 'id' to 'NSRect' (aka 'CGRect')
> 
> 
> 
> Le 20/06/13 16:18, Richard Heard a écrit :
>> No retina devices can run 10.6, therefore you can safely assume 1.0.
>> This means you can use a runtime check for the selector, and if its not 
>> available default to a 1.0 multiple
>> eg:
>> 
>>> - (NSRect)backingBounds {
>>> if ([self respondsToSelector:@selector(convertRectToBacking:)]){
>>> return [self convertRectToBacking:self.bounds];
>>> }
>>> return self.bounds;
>>> }
>> 
>> -Richard
>> 
>> On 20/06/2013, at 11:49:18 PM, Thierry Cantet > > wrote:
>> 
>>> Hello !
>>> 
>>> I have a quick question concerning Retina displays.
>>> My software uses OpenGL for displaying the pixels. However, on a Retina 
>>> screen, OpenGL behaves strangely.
>>> 
>>> There is a fix ( 
>>> https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
>>>  ) that requires you to use :
>>> 
>>>   NSRect backingBounds = [self convertRectToBacking:[self bounds]];
>>>   GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
>>>   backingPixelHeight = (GLsizei)(backingBounds.size.height);
>>>   glViewport(0, 0, backingPixelWidth, backingPixelHeight);
>>> 
>>> inside the drawRect method.
>>> 
>>> The main issue is, the /convertRectToBacking/ method exists only since OS X 
>>> 10.7, and my software still supports OS X 10.6 (so I need to build it with 
>>> a 10.6 SDK, and not 10.7).
>>> I could drop the 10.6 support, but that is not an option for now.
>>> 
>>> I have looked for another way, and I found the /backingScaleFactor/ method 
>>> (it returns the scale factor, which is 2 for Retina displays, and 1 for 
>>> other screens). But then again, this method is available only from 10.7.
>>> 
>>> So, my question is, is there any way of detecting a Retina display, but 
>>> usable with 10.6 ?
>>> 
>>> Thanks in advance :)
>>> 
>>> -- 
>>> Thierry CANTET
>>> 
>>> ___
>>> 
>>> 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/heardrwt%40gmail.com
>>> 
>>> This email sent to heard...@gmail.com
>> 
> -- 
> Thierry CANTET
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: I think I'm ready to throw in the towel - I really need help here

[Sandy McGuffog]

Inkscape - free, is a vector editor so you can export bitmaps at whatever 
resolution you want, and there are huge numbers of public domain SVG images on 
the net that you can repurpose. I use Inkscape for all my icons, etc. There's 
also a good "programmers tutorial" here: 
http://cocoawithlove.com/2009/11/creating-iphone-and-mac-icons-using.html

Sandy

On Jan 25, 2012, at 11:38 AM, Jim McGowan wrote:

>> 
>> (1) John, use this graphics app, do these 3-or-whatever things on your png 
>> graphics and bingo!
>> 
> You might want to try (re)creating your graphics with Opacity 
> (http://likethought.com/opacity), it's a great graphics app designed for 
> developers and has multi resolution support built right in, and some iOS 
> templates.  I've got nothing to do with this app, I'm just a happy user.
> 
> Jim
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: Allocating too much memory kills my App rather than returning NULL

[Sandy McGuffog]

In my experience, and I'm the author of PhotoRaw, which uses LOTS of memory for 
raw image conversion, 128MB is very optimistic. 50-70 on e.g., an iPad 1 is 
more like it, and even then there will be occasional situations where you get 
terminated.

Sandy


On Nov 9, 2011, at 11:00 PM, David Duncan wrote:

> On Nov 8, 2011, at 10:51 PM, Don Quixote de la Mancha wrote:
> 
>> It's user-configurable.  If the user asks for too big a grid, I want to be 
>> able to tell them that there isn't enough memory, then suggest they try a 
>> smaller grid.
> 
> 
> In a naive implementation using 1 byte per cell and a full duplicate of state 
> for advancement, you can support an 8192x8192 grid in 128MB of memory, which 
> while high is supportable on all devices that support iOS 5. With various 
> optimizations you can increase this size significantly of course.
> 
> But at a completely practical level, is 8K x 8K not a big enough max grid 
> size?
> --
> David Duncan
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ALAssetsLibrary and iOS5

[Sandy McGuffog]

Just looking at the code, one issue that you might be running into is that for 
ALAssetsLibrary under iOS 5, to quote from the Apple docs, "The lifetimes of 
objects you get back from a library instance are tied to the lifetime of the 
library instance." In this case, it's not at all clear to me that this 
restriction is being met. There are a couple of threads on the Apple developer 
forum discussing this.

Sandy

On Oct 27, 2011, at 6:36 PM, James Cicenia wrote:

> ALAssetsLibrary 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anyone using IKImageView?

[Sandy McGuffog]

ImageBrowser, I think.

Sandy

On Mar 17, 2010, at 5:22 PM, Brian Postow wrote:

> 
> On Mar 17, 2010, at 10:42 AM, Sandy McGuffog wrote:
> 
>> I speak from memory here, but my recollection is that IKImageView does not 
>> like going in a scrollview; you put an NSScroller next to it, and hook that 
>> to one of the IKImageView's scroller outlets. Or something like that - there 
>> is a Apple demo app that shows this.
> 
> 
> Really? Which one? IKImageViewDemo doesn't have scrollbars. 
> 
> Brian Postow
> Senior Software Engineer
> Acordex Imaging Systems
> 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anyone using IKImageView?

[Sandy McGuffog]

I speak from memory here, but my recollection is that IKImageView does not like 
going in a scrollview; you put an NSScroller next to it, and hook that to one 
of the IKImageView's scroller outlets. Or something like that - there is a 
Apple demo app that shows this.

Sandy


On Mar 16, 2010, at 11:54 PM, Brian Postow wrote:

> I have an IKImageView inside a Scrollview (actually a bit of a scrollview 
> work-around, in order to get the scrollbars to actually appear and disappear 
> correctly) and I'm trying to use the select tool. 
> 
> However, the select box isn't appearing in the correct place when the 
> imageView isn't exactly the same size as the scrollview. It doesn't matter 
> whether thescrollview is looking at the top or bottom of the imageview, if 
> the image is bigger than the scrollview by N pixels, then the select box will 
> be N pixels higher than it should be.
> 
> I sort of expected that if it was just a matter of conflicting origins, then 
> either scrolling to the top or bottom of the image would make the problem 
> disappear, but it doesn't have any effect. 
> 
> Has anyone seen anything like this?
> 
> thanks.
> 
> 
> Brian Postow
> Senior Software Engineer
> Acordex Imaging Systems
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Inconsistent results from iconForFile

[Sandy McGuffog]

Jens,

Thanks - QuickLook does indeed consistently give the same previews as Finder.  
Problem solved!

Regards,

Sandy

On Nov 28, 2009, at 8:41 AM, Jens Alfke wrote:

> 
> On Nov 27, 2009, at 10:31 PM, Sandy McGuffog wrote:
> 
>> For some files, I get a thumbnail of the file, so e.g., for a JPEG, I get a 
>> miniature of the actual image in the JPEG. But for other files, even in the 
>> same directory, I get the file type icon, so e.g., for a JPEG, the OS X JPEG 
>> icon.
>> 
>> All these files show the miniature of the image in Finder.
> 
> 
> Some files have embedded previews, or are in common formats (like JPEG) that 
> the system at a low level knows how to generate preview of — NSWorkspace etc. 
> will give you previews of those. But not all file types are like that. If 
> you're trying to get icon previews of all kinds of files, the QuickLook API 
> is the best way to do it.
> 
> —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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Inconsistent results from iconForFile

[Sandy McGuffog]

Part of my code uses:

[[NSWorkspace sharedWorkspace] iconForFile:path];

For some files, I get a thumbnail of the file, so e.g., for a JPEG, I get a 
miniature of the actual image in the JPEG. But for other files, even in the 
same directory, I get the file type icon, so e.g., for a JPEG, the OS X JPEG 
icon.

All these files show the miniature of the image in Finder.

I've also tried with [NSFileWrapper icon]. Same result.

Can anyone shed light on this?

Thanks,

Sandy___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: TIFFRepresentation, different TIFF format under Snow Leopard

[Sandy McGuffog]

Ken,

Just for clarity here, my problem, although not the original poster's,  
is not around internal representation - I'm happy with with whatever  
comes along in that regard. My problem is that if you want to write  
out a Core Image rep as TIFF, there is no obvious way to specify that  
you want the written representation to be RGB, not RGBA. Maybe there  
is a way, but I couldn't find it.


Sandy

On Oct 13, 2009, at 5:33 PM, Ken Ferry wrote:


On Tue, Oct 13, 2009 at 12:39 AM, Paul M  wrote:
Note especially this quote:
"Adobe supports TIFF issues that directly relate to Adobe products.  
If a
TIFF file is incompatible with an Adobe product ... our goal is to  
isolate
and understand the problem so that it may be corrected in future  
releases"

Taken from this page:
http://kb2.adobe.com/cps/000/13da4f4.html

This hedge is probably in there because TIFF is designed to allow  
random extensions.  There's no hope of supporting anything anyone  
could possibly put in a TIFF file.


However, hopefully a program won't put semantically necessary data  
in private extensions unless the files aren't supposed to escape  
management by that program.


That an Adobe product is so "Crappy" in this regard is surprising.  
I'm not
100% cretain, but I was under the impression that Adobe owns the  
Intelectual
Property that is the TIFF standard. They certainly support and  
foster it

to a high degree.

I agree.  Of course one should file a bug with Adobe, but I would be  
inclined to think that this problem was misdiagnosed.  Lightroom  
really ought to be able to read TIFF files with an alpha channel.


If there is indeed no api to do this, It would be reasonable to  
expect that the output format may be determined by the data comming  
in (to the image IO subsystem). If CoreImage is associating an alpha  
channel with the image, then try looking at CoreImage to either not  
add the alpha, or else to remove it prior to exporting your image.


If you cannot do this with CoreImage, try looking at NSImage or  
other imaging components (Ken suggested CGImageDestination) to see  
if the alpha can be removed prior to writing it to disk. (Basicly,  
if you cant tell it not to write the alpha, try removing the alpha  
then write it out - then file an enhancement request!).


ImageIO (i.e. CGImageDestination) is the reading and writing  
framework used by everything else.Please do file a bug, but  
please do understand:  The contract today is that ImageIO makes no  
promises about the relation between in-memory pixel format and on- 
disk format on either reading or writing.  You need to code such  
that you don't depend on it, as discussed earlier in this thread.


In particular, there has been talk of unilaterally standardizing  
everything to ARGB when it's read in to simplify CoreGraphics and  
avoid future conversions.


-Ken
Cocoa Frameworks



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: TIFFRepresentation, different TIFF format under Snow Leopard

[Sandy McGuffog]

Well, that I think depends on your definition of "crappy software". :)

The practical issue for me is that that Adobe Lightroom (at least on  
the PC) won't read an RGBA TIFF file, and if one of Adobe's premier  
packages won't read the file, then the current Apple implementation of  
the TIFF writer is, practically speaking, useless to me.


Sandy


On Oct 12, 2009, at 11:24 PM, Paul M wrote:


On 13/10/2009, at 4:39 AM, Sandy McGuffog wrote:

Actually, that occurred under 10.5 as well - what happens is that  
some operations, it would seem those involving Core Image, cause  
the internal representation to go to RGBA. Which is fine, but there  
doesn't seem to be a way to write a plain RGB format TIFF. I had to  
incorporate a third-party TIFF module to do that, as RGBA TIFF  
files aren't very compatible with anything other than Apple.


Sandy



I think what you mean to say is "RGBA TIFF files aren't very  
compatible with

crappy software".

A tiff file has tags in the header identifying the number of colour  
planes
and their arangement within the file. Any half decent tiff importer  
will
simply skip the alpha channel, if it has no use for it, and only  
read the RGB

data.



On Oct 12, 2009, at 5:07 PM, Ken Ferry wrote:

On Mon, Oct 12, 2009 at 4:36 AM, Peter C   
wrote:


I just stumble into a feature (or a bug ?), NSImage  
TIFFRepresentation
produce RGB TIFF with a layer (when open under Photoshop).  
Previously it
produce plain RGB TIFF under OS 10.5 and below. This cause some  
part of my
programs interpret wrong RGB data, expecting 3 bytes instead of 4  
bytes for
a RGB pixel.  There is no mention in the documents about this  
"feature".


Is there a way to restore the previous behavior  of  
TIFFRepresentation ?


There's 2 ways to solve your problem.
1) Use Cocoa APIs to specify 3-plane RGB image output (I'm sorry I  
have no

further information here).
2) Throw away your crappy tiff readers and get something better.


paulm


You can look at CGImageDestination to get more options, but I  
don't think

there's anything that provides control at that level.

In many cases there _must_ be data munging between the in memory  
pixel
format and the on-disk file format.  The precise munging is not  
defined on

either input or output.

That is, don't make pixel format assumptions.  The AppKit release
notes<http://developer.apple.com/mac/library/releasenotes/Cocoa/AppKit.html 
>discuss

how to avoid making pixel format assumptions in the section
"NSBitmapImageRep: CoreGraphics impedence matching and performance  
notes".


-Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: TIFFRepresentation, different TIFF format under Snow Leopard

[Sandy McGuffog]

Actually, that occurred under 10.5 as well - what happens is that some  
operations, it would seem those involving Core Image, cause the  
internal representation to go to RGBA. Which is fine, but there  
doesn't seem to be a way to write a plain RGB format TIFF. I had to  
incorporate a third-party TIFF module to do that, as RGBA TIFF files  
aren't very compatible with anything other than Apple.


Sandy


On Oct 12, 2009, at 5:07 PM, Ken Ferry wrote:

On Mon, Oct 12, 2009 at 4:36 AM, Peter C   
wrote:


I just stumble into a feature (or a bug ?), NSImage  
TIFFRepresentation
produce RGB TIFF with a layer (when open under Photoshop).  
Previously it
produce plain RGB TIFF under OS 10.5 and below. This cause some  
part of my
programs interpret wrong RGB data, expecting 3 bytes instead of 4  
bytes for
a RGB pixel.  There is no mention in the documents about this  
"feature".


Is there a way to restore the previous behavior  of  
TIFFRepresentation ?



You can look at CGImageDestination to get more options, but I don't  
think

there's anything that provides control at that level.

In many cases there _must_ be data munging between the in memory pixel
format and the on-disk file format.  The precise munging is not  
defined on

either input or output.

That is, don't make pixel format assumptions.  The AppKit release
notesdiscuss

how to avoid making pixel format assumptions in the section
"NSBitmapImageRep: CoreGraphics impedence matching and performance  
notes".


-Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Overcoming crappiness of NSSplitView - what's the magic?

[Sandy McGuffog]

Below is what I ended up doing to solve a similar problem. Which is  
really seriously ugly, but has worked for me. Your mileage may  
vary..


Sandy


- (void)splitView:(NSSplitView *)sender resizeSubviewsWithOldSize: 
(NSSize)oldSize

{
NSArray *subviewList = [sender subviews];
NSView *leftView = [subviewList objectAtIndex:0];
if ([leftView frame].origin.x != 0) {
leftView = [subviewList objectAtIndex:1];
}
NSRect leftFrame;
	leftFrame.size.width = (oldSize.width - [sender dividerThickness]) 
*splitFactor;

leftFrame.size.height = oldSize.height;
leftFrame.origin = NSMakePoint(0,0);
[leftView setFrame:leftFrame];
[sender adjustSubviews];
}

- (float)splitView:(NSSplitView *)sender constrainSplitPosition:(float) 
proposedPosition ofSubviewAt:(int)offset

{
	splitFactor = (proposedPosition+[sender dividerThickness]/2)/((float)  
[sender frame].size.width);

return proposedPosition;
}

- (float)splitView:(NSSplitView *)sender constrainMinCoordinate:(float) 
proposedMin ofSubviewAt:(int)offset

{
if (offset == 0) {
return 30;
}   
else {
return proposedMin;
}
}

- (float)splitView:(NSSplitView *)sender constrainMaxCoordinate:(float) 
proposedMax ofSubviewAt:(int)offset

{
if (offset == 0) {
		return ((float) [sender frame].size.width - (30 + [sender  
dividerThickness]));

}
else {
return proposedMax;
}   
}


On 15 Sep 2009, at 4:01 PM, Graham Cox wrote:

Ok, I'm beating my head on this one, wasting time I have better  
things to spend it on. NSSplitView is a travesty, but we're stuck  
with it, so I need to know the magic incantation of delegate methods  
and other voodoo needed to implement the following for a split view  
with one upper and one lower pane.


1. When I drag the splitter directly, it moves allowing me to  
position it where I want within the constrained min and max of the  
contained views.
2. When the window resizes I want the split to stay exactly where it  
is relative to the top of the window. I do not want it to move  
proportionally which seems to be the default. In other words the  
window resize affects the bottom pane only, even though the top one  
can be resized by the split. Whoever decided that was a sensible  
behaviour for the default anyway?
3. When the window is resized programatically as well as drag- 
resized, 2. needs to be true also.


This seems so simple and obvious that I'm finding it very  
frustrating that nothing I have tried works.


What I have tried:

- (BOOL)splitView:(NSSplitView *)splitView shouldAdjustSizeOfSubview: 
(NSView *)subview


I've tried returning NO for the times when the window is being  
resized, assuming that this would effectively lock the split in  
place. It's not even called except once when the view is  
instantiated. I'm guessing then that this is meant to indicate the  
general disposition of view splitting, called just once for all  
time. The docs are unclear on this to say the least.


- (CGFloat)splitView:(NSSplitView *)splitView constrainSplitPosition: 
(CGFloat)proposedPosition ofSubviewAt:(NSInteger)dividerIndex


This is at only called during manual dragging, so can't be used to  
constrain the split during window resize, as even though the split  
is being moved at that time, this isn't checked. In any case there's  
no way to obtain the current split position at the start of the  
window resize so I can return it to effect a "lock".


- (void)splitViewWillResizeSubviews:(NSNotification *)aNotification

This is called in both cases - dragging the split and resizing the  
window. But what can I do with it? Since there's no way to get the  
split position at the start of a resize I can't set it from here or  
anywhere else.


Any ideas what I can do?


--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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Comparing NSImages

[Sandy McGuffog]

Well, before you worry about release differences, you should probably  
worry about the "NSDeviceRGBColorSpace" - if you want consistency  
between different platforms, I'd think you should be using sRGB, Adobe  
RGB or similar.


Sandy

On Jul 23, 2009, at 11:00 PM, Benjamin Rister wrote:

We're having problems where the same code is producing corrupt  
output on certain OS versions but not others.  We're trying to track  
this down, but are running into issues trying to verify intermediate  
results in the process, in particular NSImage data.


Question 1: Is it normal for [NSImage TIFFRepresentation] to differ  
from release to release on identical images?  There are pieces of  
very basic code [1] that are producing NSImages with different  
TIFFRepresentations on the same input on the different OSes, so I'm  
not convinced that's a reliable way to tell whether it's producing  
the expected output.


Question 2: Assuming TIFFRepresentation isn't unique, what's the  
best practice to verify programmatically, say in a unit test, that  
the output matches an expected output?


Thanks,
Benjamin Rister


[1] Very basic code:
// input is NSImage* img, identical on both OSes (TIFFRepresentation  
exactly identical)


int height = [img size].height;
int width = [img size].width;

NSBitmapImageRep *imageRep = [[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:NULL
pixelsWide:width
pixelsHigh:height
bitsPerSample:8
samplesPerPixel:3
hasAlpha:NO
isPlanar:NO
colorSpaceName:NSDeviceRGBColorSpace
bytesPerRow:width * 3
bitsPerPixel:24];

NSImage *newImage = [[NSImage alloc] init];
[newImage addRepresentation:imageRep];
[imageRep release];

[newImage lockFocus];
NSRect imgRect = NSMakeRect(0,0,width,height);
[img drawInRect:imgRect fromRect:imgRect  
operation:NSCompositeSourceOver fraction:1.0f];

[newImage unlockFocus];

// output [newImage TIFFRepresentation] is different on the  
different OSes

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Best way to save a CIImage to disk

[Sandy McGuffog]

I also had (have actually) this problem. The issue appears to be that  
CoreImage seems to do its own caching. If you watch the retain counts  
on the underlying image data that you pass to CoreImage, it leave  
retains in place for a long time. Under testing, when I repeatedly  
passed an image with the same underlying data to CoreImage, the retain  
count went to 31, then stayed at 31, which to me indicates some kind  
of a caching mechanism. Even more interesting, this occurs even if the  
calls are wrapped in a autorelease pool(!). If you pass different  
images however, releases occur more often - it looks like CoreImage  
does some kind of monitoring of memory, and adjusts its behavior  
accordingly.


Sandy

I have not found any way to change this behavior.
On 05 May 2009, at 2:12 PM, Michael Ash wrote:


On Mon, May 4, 2009 at 4:58 PM, Jan-Willem Buurlage
 wrote:

I'm running a CIImage through some CIFilters, and I want to save the
returned CIImage to disk. Everything is very fast up until the  
point where I
try to actually save the image. I first create an NSBitmapImageRep  
with my
CIImage, get the needed NSData from that object, and then save it  
to disk.
Not only is this incredibly slow, Instrument shows that the memory  
gets
filled up extremely fast as well. In fact, when I input a couple  
dozen files
into my program it takes longer and longer for it to process them,  
and

eventually the application just freezes.
Here's the relevant code:

for(NSString* file in fileArray) {
.
//filter the image
CIImage* result = [self filterImage:source];

//saving to disk
NSBitmapImageRep* rep = [[NSBitmapImageRep alloc]  
initWithCIImage:result];

NSData* PNGData = [rep representationUsingType:NSPNGFileType
properties:nil];
[PNGData writeToFile:targetPath atomatically:NO];

}

Obviously there must be some better way to do this. And why does my  
memory
fill up? The leak must be in these couple of lines. If anyone can  
help me
towards the direction I should look in that would be very much  
appreciated.


Memory is filling up because of autoreleased objects created during
processing. Add an autorelease pool around your code inside your loop.

Everything is fast until you save the image because CoreImage is built
on lazy evaluation. When you apply filters and such, CoreImage doesn't
actually do any processing. All it does is build a pipeline. It's only
when you actually request the image data in some way, for example by
drawing it or by converting it to an NSBitmapImageRep, that CoreImage
actually does all the image processing and rendering. This code is
slow because that's where all the real work is actually being done.
You can't fix that unless you somehow lighten the load on CoreImage.

Mike
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Autosaving the selection in an NSTableView

[Sandy McGuffog]

Not sure about NSTableViews, but with NSOutlineViews, which I'd think  
behave the same way, the secret sauce is to make sure that your items  
have all of persistentObjectForItem, initWithPersistentObject, isEqual  
and hash consistently implemented. Reason being that what is stored to  
your prefs file is the persistent object of the selected item, and on  
restart the framework first compares hashes between the  
"reconstituted" persistent object and what has been loaded into the  
view, then, if those match, calls isEqual.


Sandy

On Apr 13, 2009, at 5:32 AM, Martin Stanley wrote:

I have a core-data document-based application that uses a  
NSTableView with an NSArrayController as its data source. I have  
managed to figure out the magic IB incantations required to save the  
column sort, order and hidden data to the shared NSDeafulsController.


What I would like to do is to also save the current selection of the  
table across application invocations. I have tried the obvious:
	- bind the array controller's selected indexes to the Shared  
Defaults controller - no luck
	- bind the tableview's selected indexes to the Shared Defaults  
controller - no luck
I even tried to get the select programmatically, but when I tried  
the callback methods I thought appropriate:

- windowControllerDidLoadNib
- applicationDidFinishLaunching
I found that the array controller was not yet loaded with data and  
therefore had no selection.


Can anyone shed some light on this?

Thanks,
Martin


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating a text service

[Sandy McGuffog]

Getting a simple text service that doesn't pop any kind of a dialog is  
pretty easy. However, if you need to show any dialogs, it gets a lot  
more complicated. If you need a (complex) example, this is a password  
manager that provides text services as part of what it does: http://sourceforge.net/projects/keychaindd/


Sandy

On Mar 16, 2009, at 4:54 AM, Andy Lee wrote:


On Mar 15, 2009, at 9:10 PM, Jonathan Haddad wrote:

I'm interested in creating a text service that would be available to
all cocoa applications.  Any advice / direction?  Thanks in advance.


I've never done it myself, but I would start with this:




I found this by searching for "services" in the Xcode documentation  
window.  (Actually Xcode found the local doc file and I converted  
the file:// URL to the online URL.)


--Andy


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Singleton Help ...

[Sandy McGuffog]

I'm pretty sure the run-time will sort that all out for you.

But I'm a bit confused here - if you're getting an  
applicationDidTerminate notification, why not just remove them there  
anyway?


Sandy

On Mar 13, 2009, at 12:54 PM, Mic Pringle wrote:


But I thought that it was best practice to remove yourself from the
notification center before terminating your application, as doesn't
the notification center live in the objective-c runtime and therefore
is always active, regardless of whether your application is or isn't ?

-Mic

2009/3/13 Mike Abdullah :
By definition, if it's a singleton, it will exist for the lifetime  
of the
program; there is no risk of the notification centre sending  
messages to a

now non-existent object.

On 13 Mar 2009, at 10:31, Mic Pringle wrote:


Hi,

I've been looking into creating a singleton class to manage some
objects that I have that I'd like to be globally available. I've  
been

reading through
http://www.cocoadev.com/index.pl?SingletonDesignPattern and all  
looks

well except I now have the following question ...

I'd like my singleton to observe the NSWorkspace notifications
applicationDidLaunch and applicationDidTerminate. I can setup the
observations in the init method, but how to I go about removing  
them ?

You would normally do in the dealloc method, but it seems you're not
meant to override dealloc in a singleton ? Would it suffice to put
them in the overridden release method ? If so, does this get called
automatically when I close the application ?

If I can't remove the notifications, I could end up with the
notification centre try to foward them to an object that no longer
exists.

Thanks

-Mic
___

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:

http://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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ImageAndTextCell rendering weirdness

[Sandy McGuffog]

Well, I haven't seen this specific behavior. But one thought is to  
check that your images have their size set - as initialized from a  
[NSImage imageNamed:], size is not set(!). This can cause all sort of  
havoc. Second comment: there are actually several different versions  
of ImageandTextCell in different developer docs; you might want to try  
the more recent versions, if you're not already. Depending on which  
version you have, the setSize may be being done for you. Or not.


Sandy


On Jan 17, 2009, at 8:26 PM, Andrew Shamel wrote:


Greetings Cocoa-Dev!

I am having the hardest time with a persistent and strange error  
with Apple's ImageAndTextCell in my NSOutlineView.


I have the ImageAndTextCell set to be the outline's data cell via  
NSTableColumn's -setDataCell: method, and I set the image of the  
cell in the outlineView's delegate, using -  
(void)outlineView:willDisplayCell:forTableColumn:item:  And here's  
where the trouble starts.


The problem I am encountering is this: When I have an image set in  
the cell, and I go to edit the text of the *first* item in any  
particular set of children, after the first keystroke, the text  
field goes haywire, turning white, with the text appearing only as  
shadow lines, and editing stops.  If I click off the cell, the mess  
goes away, the one keystroke's worth of edit remains, but does not  
get noticed by the bindings.


Here is a picture of what happens: http://www.pileofdebris.com/editError.png

Does anyone have any thoughts about why this might be happening?   
I've figured out that if my willDisplayCell: delegate method is  
empty, this does not happen.  Here is the code for that method,  
should it be of any help.


- (void)outlineView:(NSOutlineView *)outlineView willDisplayCell: 
(id)cell forTableColumn:(NSTableColumn *)tableColumn item:(id)item

{
NSManagedObject *node = [item representedObject];
NSString *type = [node valueForKey:@"type"];
NSString *tag = [node valueForKey:@"tag"];

if ([type isEqual:@"collection"]) {
[cell setImage:[self defaultFolderImage]];
} else if ([type isEqual:@"library"]) {
if ([tag isEqual:@"booksLibrary"]) {
[cell setImage:[self booksLibraryImage]];
} else if ([tag isEqual:@"articlesLibrary"]) {
[cell setImage:[self articlesLibraryImage]];
} else {
[cell setImage:[self articlesLibraryImage]];
}
} else if ([type isEqual:@"section"]) {
[cell setImage:nil];
[cell setEditable:NO];
[cell setSelectable:NO];
} else if ([type isEqual:@"smartCollection"]) {
[cell setImage:[self smartFolderImage]];

}
}

Thanks so much for any input people can offer.

pax,

Andy S.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stumped on memory problem :(

[Sandy McGuffog]

Haven't run the code, but I'd think that what you want is:

NSMutableArray *array = [[NSMutableArray alloc] init];

Sandy

On 02 Jan 2009, at 3:14 AM, Jacob Rhoden wrote:

I have read the memory management documentation over and over but  
still cannot work out the problem with this code, can anyone see it?  
I have spent hours on this!


+(NSMutableArray*)getStrings {
   NSMutableDictionary* dict = [[NSMutableDictionary alloc] init];
   [dict setValue: @"" forKey: [NSString stringWithString:@"one"]];
   [dict setValue: @"" forKey: [NSString stringWithString:@"two"]];

   NSMutableArray *array = [[NSMutableArray array] init];
   NSEnumerator* keyEnum = [dict keyEnumerator];
   NSString* key;
   while ((key = [keyEnum nextObject])) {
   [array addObject: key];
   }
   [dict release];

   return [array autorelease];
}

// Here is where I call the above function
NSMutableArray* a =[StringHelper getStrings];
[a retain];
for(int i=0;i %@",(NSString*)[a objectAtIndex: i]);
}
[a release];

AFTER the code is complete I see the following message, the address  
location is always the pointer to the array created in the  
getStrings method.


2009-01-02 12:07:29.277 Test[5184:813] *** -[CFArray release]:  
message sent to deallocated instance 0x132950


Any help muchly appreciated. I have tried with and without the [a  
retain] and [a release].

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com

This email sent to mcguff...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Display Mail type outlineView numbers

[Sandy McGuffog]

You're probably going to have to display an image in an outlineview  
cell. Start by looking at ImageAndTextCell in the DragNDropOutlineView  
Developer example


The alternative is to place NSAttributedStrings that have images  
imbedded in the outlineview. But I could never get the formatting to  
work well enough to make the AttributedStrings approach workable.


Sandy

On 01 Jan 2009, at 4:59 PM, vince wrote:


Thanks for the help.
I would like to display the small blue circle and associated numbers  
that

refer to the amount of entries in an outlineView group. Documentation?


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com