Re: Bitmaps, colorspaces, etc.
I don't know anything about these methods. But in colour space work, "retagging" would usually mean changing the attached colour profile without changing the pixel values. For example, if an image starts as AppleRGB, it could be tagged as sRGB. This is not a conversion. The pixel values, numbers, are unchanged. So the meaning of the pixel values, now interpreted as sRGB rather than AppleRGB, would change, and the colour would shift. At a push "retagging" an untagged image would give a specific meaning to the pixels rather than a default/device dependent meaning. So (pure speculation) maybe creating as CalRGB would create it with some unknown/default profile and you can later tag it. That would imply that the main job of colorSpaceName is to deliver information on the number of components, rather than how to colour map. On 21 December 2015 at 01:15, Graham Cox wrote: > I’m trying to understand how properly to use colorspaces with bitmaps. > > In my app’s Export function, we’d like to offer the ability to choose a > colorspace for the exported image, in whatever format the user chose. My > thoughts were to use NSBitmapImageRep to capture the image, then use its > -representationUsingType:properties: method to get the image data in > whatever format before writing it to disk. So far so good. > > NSBitmapImageRep accepts a ‘colorspaceName’ parameter when it’s created, > and these can be one of the following: > > • NSCalibratedWhiteColorSpace > • NSCalibratedBlackColorSpace > • NSCalibratedRGBColorSpace > • NSDeviceWhiteColorSpace > • NSDeviceBlackColorSpace > • NSDeviceRGBColorSpace > • NSDeviceCMYKColorSpace > • NSNamedColorSpace > • NSCustomColorSpace > > Which are all strings, and seem to represent a very generic non-specific > kind of colorspace. > > These don’t match with the colorspaces known to the system as returned by > +[NSColorSpace availableColorSpacesWithModel:], which returns an array of > NSColorSpace objects, each of which is able to return a -localizedName > property, which are very specific, and do not relate to the above names at > all. > > How do I bridge this impedance mismatch? If the user wants to Export using > a specific, named colorspace, as chosen for example from a list of the > colorspaces returned by the +availableColorSpaces method, how should I go > about creating the appropriate bitmap? I see that NSBitmapImageRep has > methods such as -bitmapImageRepByRetaggingWithColorspace: and > -bitmapImageRepByConvertingToColorSpace:renderingIntent: > > What does ‘retagging’ mean? Presumably converting duplicates the bitmap, > so could be a memory strain. This seems unnecessary if I could create the > bitmap with a specific colorspace in the first place. > > Also, when creating a bitmap, what does using ‘NSNamedColorspace’ do? > Which named colorspace? What about ‘NSCustomColorSpace’? These seem only to > indicate what general kind of colorspace to expect, not a specific one. > > The problem here is that I can find no documentation that goes anywhere > near explaining this. Maybe NSBitmapImageRep is too high level and I need > to drop down to CGImageRef? That class does seem to take a specific > CGColorSpace object, though how I get there from +[NSColorSpace > availableColorSpecs] is unclear. > > Am I even asking sensible questions? This sort of impedance mismatch > usually suggests a conceptual misunderstanding somewhere, but without a > clear explanation of how colorspaces and bitmaps are used, I can’t see > where I may have gone wrong. > > Anyone able to illuminate? > > —Graham > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/aandi%40quite.com > > This email sent to aa...@quite.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
iOS - force app to be restarted in the background.
Hi all. I'm trying to debug an issue on iOS where it appears that our app isn't behaving properly after being put in Airplane Mode overnight and then taken off of it. What I'm seeing in the crash logs are messages about BKUnsuspendLimit which leads me to think that the app is being restarted in the background and it's not reconfiguring itself properly or going through the normal startup process in that case. BKUnsuspendLimit exceeded 15 wakes in 300 sec To test this, is there any way to tell the OS to relaunch the app in the background? Thanks in advance. Alex Zavatone ___ 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: Best way to get a file path for presentation to the user
> On Dec 19, 2015, at 12:31 PM, Lee Ann Rucker wrote: > > Popup style is appropriate where the most important info is the last part but > sometimes they want to see the whole path. Standard style is for where the > whole path is important. It is an excellent control. -rags ___ 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: CGContextClipToRects: invalid context 0x0.
> On Dec 18, 2015, at 2:36 PM, Quincey Morris > wrote: > > On Dec 18, 2015, at 08:59 , Richard Charles wrote: >> >> Apple’s frameworks do not have symbols. > > IIRC several OS X versions ago, Apple use to release versions of the system > frameworks that included symbols, but this wasn’t very useful because they > came out so much later than the OS itself. I don’t know if they’ve done that > for recent versions. You could look in the developer downloads to find out. Debug symbols for Cocoa frameworks are no where to be found. > Regarding the original problem (since no one who knew anything jumped in), I > think I’ve seen this complained of occasionally during the last couple of > years. Sometimes it indicates that internal Apple code wasn’t changed when > API was deprecated. It works fine, but as OS versions march on the complaints > from the deprecated API get more insistent. > > So it may not be anything to do with your code. The best thing to do is file > a radar and let them tell you not to worry about it. I requested technical support for this issue and was promptly told to file a bug report. Thanks for the input. --Richard Charles ___ 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: CGContextClipToRects: invalid context 0x0.
> On Dec 18, 2015, at 7:44 PM, Uli Kusterer > wrote: > > On 18 Dec 2015, at 17:59, Richard Charles wrote: >> Debugging a linked library without symbols is difficult (bordering on >> impossible). > > It's not easy, but far from impossible. If you can read assembly, you can > usually figure out quite a lot. The debugger will disassemble stack frames > for you when you step into them. It would be a little easier for Objective-C > code, where all method names are registered publicly, as are class names and > a good part of each object's layout. > > It helps to familiarize oneself with LLDB's commands. Particularly what > registers 64-bit apps use to store parameters and how to print them from > inside a method call, and how the 'po' command works for printing objects. The difficult thing was that the CGPostError breakpoint stopped at the beginning of the CGPostError function. #0 0x7fff8e5686c7 in CGPostError () #1 0x7fff8e568798 in handle_invalid_context () #2 0x7fff8d5ad2c0 in -[NSView _drawRect:clip:] () At this breakpoint the registers contained passed in parameters for CGPostError () but what was needed was information on -[NSView _drawRect:clip:] (). What would have helped is a conditional symbolic breakpoint after the fact. Break on -[NSView _drawRect:clip:] when followed by a CGPostError with the registers containing the parameters passed into -[NSView _drawRect:clip:]. There are way too many -[NSView _drawRect:clip:] calls to manually step through each one waiting for the one followed by CGPostError. > But for complaints about an invalid context, it sometimes helps to verify > that any API you use from the library this error comes from is documented to > accept NULL where you pass it NULL. And in this case I'd also print the > current CGContext before any calls you make, and ensure that you save and > restore your context before and after any calls where you change it, > especially if you create your own contexts. And ensure that you retain any > contexts that you're keeping around across calls, and verifying that your > window is visible and not deferred if you try to draw in it. (This is all > assuming you're not making a basic mistake like calling drawRect: directly or > (even indirectly) requesting redraws from inside drawRect: I am using an OpenGL context and have checked everything. My actual problem occurs when choosing Revert To > Browse All Versions. > If none of this helps, a common occurrence of weird behaviour like this is > also sometimes screwing up internal state by using thread-safe API that is > not documented to support being used from more than one thread at once, or > API that's not safe to use from non-main threads at all, from several > threads. Any if that ring a bell? I put the application into single threaded mode and get the same error. I requested technical support for this issue and was told to file a bug report so we shall see what happens. Thanks for the input. --Richard Charles ___ 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: CGContextClipToRects: invalid context 0x0.
I really don't see why you need to debug Apple's frameworks. When you break in the debugger or get a crash report symbolicated, there are enough symbols in there to see where you are—if you are in a call sequence inside Apple's frameworks. If you're not seeing them, then you're not there. The time I saw your real issue was when I was trying to unravel some legacy code that was forcing changes to the view hierarchy when in a drawRect: which is really, really bad, and it was mixing up auto layout and manual layout—a field editor and simulated combo box were involved. Look at your code for things like that and forget about your perceived issue with the frameworks. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On Dec 15, 2015, at 3:12 PM, Richard Charles wrote: > > CGContextClipToRects ___ 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
Settings.bundle settings disappear while running
Working on an application with some App settings in the Settings.bundle. They do not appear when running the application in debug - but if I quite the app and launch the app settings from Settings.app they display. Is there a trick to get them to be avalable while running the application? There is a NSUserDefaultsDidChangeNotification that I thought I would observe in changes in the app settings, but I can’t if they don’t display. Thanks, Eric ___ 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
applicationSupportDirectory access for admin and standard users
Hi My app seems to be having trouble reading and writing to the applicationSupportDirectory depending on whether the logged in user is an admin or standard user. I don’t use the sandbox. NSURL *appSupportDir = [[NSURL alloc] initFileURLWithPath:[[NSFileManager defaultManager] applicationSupportDirectory] isDirectory:YES]; Is there anything I need to be aware of here? Thanks J ___ 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: applicationSupportDirectory access for admin and standard users
On Mon, 21 Dec 2015 22:16:39 +, Jonathan Mitchell said: >My app seems to be having trouble reading and writing to the >applicationSupportDirectory depending on whether the logged in user is >an admin or standard user. >I don’t use the sandbox. > >NSURL *appSupportDir = [[NSURL alloc] initFileURLWithPath: >[[NSFileManager defaultManager] applicationSupportDirectory] isDirectory:YES]; > >Is there anything I need to be aware of here? What's "trouble"? What error code do you get trying to write to the directory? Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: applicationSupportDirectory access for admin and standard users
On Dec 21, 2015, at 14:16 , Jonathan Mitchell wrote: > > Is there anything I need to be aware of here? Try using ‘URLsForDirectory:inDomains:' instead. But what does “trouble” mean? Are you having trouble getting the correct URL, or trouble accessing the directory at the URL? (Error messages would be a help.) ___ 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: CGContextClipToRects: invalid context 0x0.
> On Dec 21, 2015, at 1:31 PM, Gary L. Wade > wrote: > > I really don't see why you need to debug Apple's frameworks. When you break > in the debugger or get a crash report symbolicated, there are enough symbols > in there to see where you are—if you are in a call sequence inside Apple's > frameworks. If you're not seeing them, then you're not there. In retrospect I agree, it was somewhat pointless. Like a good developer I was simply following instructions given in the error message written and placed there by Apple and also trying to improve my debugging skills. Error under OS X El Capitan 10.11.2 which is a little different that the previously reported error under OS X Yosemite 10.10.5. : Set a breakpoint at CGSLogError to catch errors as they are logged. : CGSGetSystemWindow: Invalid window > The time I saw your real issue was when I was trying to unravel some legacy > code that was forcing changes to the view hierarchy when in a drawRect: which > is really, really bad, and it was mixing up auto layout and manual layout—a > field editor and simulated combo box were involved. I actually was able to reproduce the initial first part of the issue with a standard Xcode 7.2 project template application. So it is time to give up and move on. It appears Apple will need to fix this. I updated bug report 23955382. --Richard Charles ___ 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: CGContextClipToRects: invalid context 0x0.
> On 16 Dec 2015, at 10:12 AM, Richard Charles wrote: > > : CGContextClipToRects: invalid context 0x0. This is a serious error. > This application, or a library it uses, is using an invalid context and is > thereby contributing to an overall degradation of system stability and > reliability. This notice is a courtesy: please fix this problem. It will > become a fatal error in an upcoming update. This has to be the Chicken Little of error messages. Surely the first thing any CG…() function that takes a context does is to assert that the context isn’t nil, and if not branch to CGPostError and do nothing else. Therefore it’s actually completely harmless. Of course it indicates an error further up, but the outcome is just a no-op. The alarmist tone of the message is to make you do something to investigate this, and to that end it works, but the problem seems to be that the only sources of these errors now are Apple’s own code. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
