Re: +underPageBackgroundColor
On Sat, Aug 04, 2012 at 08:48:20AM +1000, Graham Cox wrote: > > On 04/08/2012, at 6:55 AM, "Gary L. Wade" > wrote: > > > That "color" is actually a pattern. What are you doing that gives you the > > unexpected result? > > I'm expecting it to be a pattern, with a fairly obvious linen texture. > > I get the colour and i use it to -setBackgroundColor: on my scrollview (which > has a custom clip view so that the "page" is centered when it becomes smaller > than the visible rect, so revealing the background). > > If I create a colour directly from a texture image, it works fine, but using > this, I get a pale cream colour with no apparent texture. I'm getting the pattern when I use it with -setBackgroundColor: on a scrollview. What do you get if you try it on an empty scrollview, perhaps in a new project just in case there's something else that prevents it from drawing? Marcus smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in showOpenPanel on ML
Anyone an idea? Does my own app need to be codesigned for this to work? Thanks, - Koen. > On 03/08/2012, at 11:35 AM, Koen van der Drift wrote: > >> After updating to M and Xcode 4.4 I get a crash in the >> beginSheetModalForWindow part of the showOpenPanel part. > >> #1 0x7fff8a9c883a in Security::MacOSError::throwMe(int) () >> #2 0x7fff8a8fb224 in Security::CodeSigning::SecStaticCode::signature() >> () >> #3 0x7fff8a8fb449 in >> Security::CodeSigning::SecStaticCode::verifySignature() () >> #4 0x7fff8a8fb25e in >> Security::CodeSigning::SecStaticCode::validateDirectory() () >> #5 0x7fff8a8fb916 in >> Security::CodeSigning::SecStaticCode::validateNonResourceComponents() () >> #6 0x7fff8a8f0601 in validate(Security::CodeSigning::SecStaticCode*, >> Security::CodeSigning::SecRequirement const*, unsigned int) () >> #7 0x7fff8a8f0470 in SecStaticCodeCheckValidityWithErrors () >> #8 0x7fff9163c44a in QLCheckAppleSignature () >> #9 0x7fff9160e375 in _QLLoadPluginAtURL () > ___ 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: crash in showOpenPanel on ML
On 4 Aug 2012, at 12:35, Koen van der Drift wrote: > Anyone an idea? Does my own app need to be codesigned for this to work? Well any app should really be codesigned with Developer ID these days, though that's probably not causing the crash. Sign it and see what happens. ___ 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: crash in showOpenPanel on ML
On 04/08/2012, at 9:35 PM, Koen van der Drift wrote: > Anyone an idea Well, does the problem go away if you temporarily remove the QL plugins? If it does, add them back in one at a time until you find the one causing the issue. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in showOpenPanel on ML
On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote: > Well any app should really be codesigned with Developer ID these days, though > that's probably not causing the crash. Sign it and see what happens. I don't have a paid dev account, so am unable to code sign it. :) I'll make a test app to see if that one gives the same error. - Koen. ___ 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: crash in showOpenPanel on ML
On Aug 4, 2012, at 8:42 AM, Graham Cox wrote: > Well, does the problem go away if you temporarily remove the QL plugins? If > it does, add them back in one at a time until you find the one causing the > issue. > Disabling all plugins (I put them in a different folder) including a logout/login did not solve the problem. I'll keep digging, thanks for thinking along. - Koen. ___ 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: crash in showOpenPanel on ML
On Aug 4, 2012, at 8:55 AM, Koen van der Drift wrote: > > On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote: > >> Well any app should really be codesigned with Developer ID these days, >> though that's probably not causing the crash. Sign it and see what happens. > > I don't have a paid dev account, so am unable to code sign it. :) > > I'll make a test app to see if that one gives the same error. More info: I have another project that I tested (also not signed), and I don't get the crash there. However, it is a NSDocument based app, so I am not calling the NSPanel code myself, it is taken care of. The app that has the crash is CoreData based and I implemented my own openPanel code, following the Apple sample code. - Koen. ___ 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: crash in showOpenPanel on ML
O, just found this: http://www.openradar.appspot.com/11685851 - Koen. On Aug 4, 2012, at 9:42 AM, Koen van der Drift wrote: > > On Aug 4, 2012, at 8:55 AM, Koen van der Drift > wrote: > >> >> On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote: >> >>> Well any app should really be codesigned with Developer ID these days, >>> though that's probably not causing the crash. Sign it and see what happens. >> >> I don't have a paid dev account, so am unable to code sign it. :) >> >> I'll make a test app to see if that one gives the same error. > > More info: > > I have another project that I tested (also not signed), and I don't get the > crash there. However, it is a NSDocument based app, so I am not calling the > NSPanel code myself, it is taken care of. The app that has the crash is > CoreData based and I implemented my own openPanel code, following the Apple > sample code. > > - Koen. > ___ 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: crash in showOpenPanel on ML
On 4 Aug 2012, at 13:55, Koen van der Drift wrote: > > On Aug 4, 2012, at 8:35 AM, Mike Abdullah wrote: > >> Well any app should really be codesigned with Developer ID these days, >> though that's probably not causing the crash. Sign it and see what happens. > > I don't have a paid dev account, so am unable to code sign it. :) A) Your customers aren't going to be very happy about that B) You can still codesign with a self-signed certificate, and really should have been doing so since the 10.5 days ___ 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
Power Nap causing NSTimer to fire immediately
When our software is running and the Mac goes into Power Nap, our NSTimers (which are fire-once and set to 3 hour periods) are firing immediately, so the software does the timer work and installed a new fire-once timer for 3 hours later. Except that one of course fires immediately and it just keeps going. How can we prevent this? I'd like our app to stop completely (but not quit of course) during Power Nap. Thanks, Trygve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in showOpenPanel on ML
On Aug 4, 2012, at 10:08 AM, Mike Abdullah wrote: > A) Your customers aren't going to be very happy about that I have no apps in the wild (yet). Of course I plan to do that once I have something that is ready to release in the MAS. :) > B) You can still codesign with a self-signed certificate, and really should > have been doing so since the 10.5 days I didn't know that, thanks for pointing that out. - Koen. ___ 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: crash in showOpenPanel on ML
Code signing and the MAS are distinct. All apps in the MAS are signed. Not all signed apps are in the MAS. All apps, MAS or not, should be signed nowadays. (Sent from my iPhone.) -- Conrad Shultz On Aug 4, 2012, at 8:26, Koen van der Drift wrote: > I have no apps in the wild (yet). Of course I plan to do that once I have > something that is ready to release in the MAS. :) ___ 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: Power Nap causing NSTimer to fire immediately
> When our software is running and the Mac goes into Power Nap, our NSTimers > (which are fire-once and set to 3 hour periods) are firing immediately, so > the software does the timer work and installed a new fire-once timer for 3 > hours later. > > Except that one of course fires immediately and it just keeps going. > > How can we prevent this? > > I'd like our app to stop completely (but not quit of course) during Power > Nap. Just a follow-up. It seems our app shouldn't be able to do anything during power nap, but something is causing weirdness. Anyone see anything like this with NSTimers on 10.8? Trygve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in showOpenPanel on ML
On Aug 4, 2012, at 9:08 AM, Koen van der Drift wrote: > I'll keep digging Well, the problem is gone. After reading the rdar I mentioned in an earlier email that the problem was solved by creating a new project, I decided to remove my project settings, and the xuserdata folder. After a Clean and Rebuild, the problem was gone. Glad it is solved, but not too satisfactory either, since I can only guess now which setting was the culprit. Regarding the responses about code signing: point well taken, and I am going to look into that. - Koen. ___ 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: Power Nap causing NSTimer to fire immediately
I am not at all sure about the details but I think your app is receiving some sort of notification that power sleep is occurring in order to allow it to do what it needs to do in that situation. My guess is that all timers are caused to expire because when asleep they will not and then, when wake up occurs, the app is hung waiting for events that will never happen. I don't know how, perhaps someone else on this list can respond, but you should, when your timers fire prematurely, determine if power sleep is occurring and act accordingly. On Aug 4, 2012, at 11:47 AM, Trygve Inda wrote: >> When our software is running and the Mac goes into Power Nap, our NSTimers >> (which are fire-once and set to 3 hour periods) are firing immediately, so >> the software does the timer work and installed a new fire-once timer for 3 >> hours later. >> >> Except that one of course fires immediately and it just keeps going. >> >> How can we prevent this? >> >> I'd like our app to stop completely (but not quit of course) during Power >> Nap. > > Just a follow-up. It seems our app shouldn't be able to do anything during > power nap, but something is causing weirdness. Anyone see anything like this > with NSTimers on 10.8? > > Trygve > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/3tothe4th%40comcast.net > > This email sent to 3tothe...@comcast.net Charlie Dickman 3tothe...@comcast.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
10.8 copiesOnScroll, -setNeedsDisplayInRect: ignored during scrolling
I'm working on a scrollable grid view and noticed that its appearance during scrolling has regressed since installing 10.8. This grid view loads content in the background and calls -setNeedsDisplayInRect: (thread-safely) as content becomes available. With copy-on-scroll enabled, -setNeedsDisplayInRect: seems to be ignored until scrolling stops, at which point the content snaps in. With copy-on-scroll disabled, the view displays normally, but is less performant than the copy-on-scroll version running on 10.7. Is there a way to have these setNeedsDisplayInRect: calls respected during scrolling? Thanks for any guidance! 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.8 copiesOnScroll, -setNeedsDisplayInRect: ignored during scrolling
On Aug 4, 2012, at 14:35 , Dave Keck wrote: > I'm working on a scrollable grid view and noticed that its appearance > during scrolling has regressed since installing 10.8. > > This grid view loads content in the background and calls > -setNeedsDisplayInRect: (thread-safely) as content becomes available. > > With copy-on-scroll enabled, -setNeedsDisplayInRect: seems to be > ignored until scrolling stops, at which point the content snaps in. > With copy-on-scroll disabled, the view displays normally, but is less > performant than the copy-on-scroll version running on 10.7. > > Is there a way to have these setNeedsDisplayInRect: calls respected > during scrolling? Could you clarify: you're talking about the content of the area exposed by the scroll, yes? Or the previously-drawn area that's actually in motion? For the latter, it seems hardly surprising that the content wouldn't appear until you stop scrolling, since by setting the copy-on-scroll flag you've promised that the old view contents don't change during scrolling. For the former, what do you actually see? A duplicate of the contents that were moved by the scrolling? The window background color? Placeholder content that you provide while the content is being loaded? If the scroll view is using CA to do the scrolling (or, perhaps, using it more aggressively than in the past), then it might not be surprising that 'setNeedsDisplayInRect:' merely causes an already-rendered layer to be re-displayed, rather than causing the layer to be re-rendered, if an animation is in progress. I also wonder if NSView's "layerContentsRedrawPolicy" has anything to do with the results, though I'm puzzled to suggest which view in the scroll view hierarchy would be the place to change the policy. (Also, the documentation tends to suggest that the policy applies only during resizing, not during animations generally, so this may be an irrelevance.) ___ 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: 10.8 copiesOnScroll, -setNeedsDisplayInRect: ignored during scrolling
Hi Quincey, > For the latter, it seems hardly surprising that the content wouldn't appear > until you stop scrolling, since by setting the copy-on-scroll flag you've > promised that the old view contents don't change during scrolling. The docs don't say one way or another, but on both 10.7 and 10.8, setNeedsDisplayInRect: is respected during scrolling when copy-on-scroll is enabled -- that is, invalidated regions are redrawn even if the regions were part of the copied region. I'm afraid I sent my question before doing my due diligence though, so in the interest of the archives: the reason the invalidated regions weren't being redrawn during scrolling was because the block that calls -setNeedsDisplayInRect: was scheduled to execute on the main thread via dispatch_async(). Due to a change in either NSScrollView, NSClipView, or CFRunLoop in 10.8, these blocks are only executed after scrolling has stopped. Instead of dispatch_async(), one can use CFRunLoopPerformBlock() along with CFRunLoopWakeUp() to have the block executed on the main thread during scrolling. Thanks for your suggestions Quincey, 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.8 copiesOnScroll, -setNeedsDisplayInRect: ignored during scrolling
On Aug 4, 2012, at 4:43 PM, Dave Keck wrote: > I'm afraid I sent my question before doing my due diligence though, so > in the interest of the archives: the reason the invalidated regions > weren't being redrawn during scrolling was because the block that > calls -setNeedsDisplayInRect: was scheduled to execute on the main > thread via dispatch_async(). Due to a change in either NSScrollView, > NSClipView, or CFRunLoop in 10.8, these blocks are only executed after > scrolling has stopped. Instead of dispatch_async(), one can use > CFRunLoopPerformBlock() along with CFRunLoopWakeUp() to have the block > executed on the main thread during scrolling. I'm unsure of the wisdom of this approach. Presumably the scroll view is intentionally blocking the runloop, and thus assuming that the runloop will not fire its event sources until after the scrolling is complete. By waking up the runloop, you're violating that assumption and could be causing work the scrollview has enqueued to be performed sooner than expected. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.8 copiesOnScroll, -setNeedsDisplayInRect: ignored during scrolling
> I'm unsure of the wisdom of this approach. Presumably the scroll view is > intentionally blocking the runloop, and thus assuming that the runloop will > not fire its event sources until after the scrolling is complete. By waking > up the runloop, you're violating that assumption and could be causing work > the scrollview has enqueued to be performed sooner than expected. During a single scrolling maneuver in 10.8.0, the run loop toggles many times between NSDefaultRunLoopMode and NSScrollEventCoallescing. I suppose I could check whether the main run loop is in the default mode before waking it up, but the overheard of that likely defeats the purpose, especially considering the inherent race condition. In the end, waking the main thread up at the wrong time (while it's in NSScrollEventCoallescing) probably wastes a mach_msg_send, a mach_msg_receive, and 20 instructions as the scrolling machinery sees that there's no new event and goes back to sleep or times-out and returns to the NSApplication loop. ___ 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
