^Block statement considered harmful for callbacks?
Blocks in Obj-C seem convenient and powerful but in fact they are very dangerous because they retain all objects referenced from the block and thereby can implicitly create circular references. If you are not vigilant about every object you mention in the block, you can create one, two or more cycles of circular references causing your objects to never be freed afterwards. This breaks encapsulation of objects with block properties (e.g. MyAnimation.completionBlock) and forces the users of such objects to always keep in mind what they can, and what the cannot write in the block body, and still they can shoot themselves in the feet at any moment by losing vigilance. It seems to me that it's much better to drop the convenience of blocks in favor of safety and full control of retain/assign relationships between my objects. This is a shocker for me too, but I do not see a good solution to this problem. The solution suggested in Session 712 WWDC 2012 is ugly - call some kind of cancel method for every block when it's no longer needed. Even with ARC, declaring a weak ref to self and then strong ref to weak ref inside the block is ugly too - you have to add this crap to each and every block you write. Thoughts? ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 09:20, Oleg Krupnov oleg.krup...@gmail.com wrote: Blocks in Obj-C seem convenient and powerful but in fact they are very dangerous because they retain all objects referenced from the block and thereby can implicitly create circular references. If you are not vigilant about every object you mention in the block, you can create one, two or more cycles of circular references causing your objects to never be freed afterwards. This breaks encapsulation of objects with block properties (e.g. MyAnimation.completionBlock) and forces the users of such objects to always keep in mind what they can, and what the cannot write in the block body, and still they can shoot themselves in the feet at any moment by losing vigilance. It seems to me that it's much better to drop the convenience of blocks in favor of safety and full control of retain/assign relationships between my objects. This is a shocker for me too, but I do not see a good solution to this problem. The solution suggested in Session 712 WWDC 2012 is ugly - call some kind of cancel method for every block when it's no longer needed. Even with ARC, declaring a weak ref to self and then strong ref to weak ref inside the block is ugly too - you have to add this crap to each and every block you write. Your argument can equally well be applied to any object that keeps strong references to other objects. It's not blocks that are doing any of the above, it's reference counting. And we know that the issues are there – we just choose to have them because the issues with the less leaky solutions are even more severe (especially in C like languages). Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
Tom, I disagree, because unlike other objects with strong refs, or say @property(retain), the strong refs in blocks are created implicitly and it's just too easy to let them slip out of attention. There is no direct command to create the strong ref, unlike @property(retain). All you do is *mention* self or even an ivar, and voila, you're done. I wish there was a safe and elegant solution to this, like we did with proxy for NSTimer. On Thu, Apr 25, 2013 at 11:28 AM, Tom Davie tom.da...@gmail.com wrote: On 25 Apr 2013, at 09:20, Oleg Krupnov oleg.krup...@gmail.com wrote: Blocks in Obj-C seem convenient and powerful but in fact they are very dangerous because they retain all objects referenced from the block and thereby can implicitly create circular references. If you are not vigilant about every object you mention in the block, you can create one, two or more cycles of circular references causing your objects to never be freed afterwards. This breaks encapsulation of objects with block properties (e.g. MyAnimation.completionBlock) and forces the users of such objects to always keep in mind what they can, and what the cannot write in the block body, and still they can shoot themselves in the feet at any moment by losing vigilance. It seems to me that it's much better to drop the convenience of blocks in favor of safety and full control of retain/assign relationships between my objects. This is a shocker for me too, but I do not see a good solution to this problem. The solution suggested in Session 712 WWDC 2012 is ugly - call some kind of cancel method for every block when it's no longer needed. Even with ARC, declaring a weak ref to self and then strong ref to weak ref inside the block is ugly too - you have to add this crap to each and every block you write. Your argument can equally well be applied to any object that keeps strong references to other objects. It's not blocks that are doing any of the above, it's reference counting. And we know that the issues are there – we just choose to have them because the issues with the less leaky solutions are even more severe (especially in C like languages). Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 09:34, Oleg Krupnov oleg.krup...@gmail.com wrote: Tom, I disagree, because unlike other objects with strong refs, or say @property(retain), the strong refs in blocks are created implicitly and it's just too easy to let them slip out of attention. There is no direct command to create the strong ref, unlike @property(retain). All you do is *mention* self or even an ivar, and voila, you're done. I wish there was a safe and elegant solution to this, like we did with proxy for NSTimer. I'm not really convinced that the fact that these objects are easier to dynamically create makes the problem that retain counting inherently can't deal with retain cycles any worse. That said, I wonder if the correct solution to what some are clearly finding an issue here is to look to the compiler. At least superficially, I could see it being possible to detect a lot of cycles with a static analyser. Obviously you couldn't detect all of them, but this would probably get a good way to stomping on the you used an ivar here, and self retains the block, that's bad m'kay bugs. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
I don't agree, blocks are very powerful. I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings when a block reference to a property caused a retain cycle. This is how I found it and why I mentioned it in another thread in the first place. I haven't tested it extensively, but it looks as if the compiler recognises these situations easily and then tells you about it. So I wouldn't call blocks dangerous at all… Op Apr 25, 2013, om 10:21 AM heeft Tom Davie tom.da...@gmail.com het volgende geschreven: On 25 Apr 2013, at 09:34, Oleg Krupnov oleg.krup...@gmail.com wrote: Tom, I disagree, because unlike other objects with strong refs, or say @property(retain), the strong refs in blocks are created implicitly and it's just too easy to let them slip out of attention. There is no direct command to create the strong ref, unlike @property(retain). All you do is *mention* self or even an ivar, and voila, you're done. I wish there was a safe and elegant solution to this, like we did with proxy for NSTimer. I'm not really convinced that the fact that these objects are easier to dynamically create makes the problem that retain counting inherently can't deal with retain cycles any worse. That said, I wonder if the correct solution to what some are clearly finding an issue here is to look to the compiler. At least superficially, I could see it being possible to detect a lot of cycles with a static analyser. Obviously you couldn't detect all of them, but this would probably get a good way to stomping on the you used an ivar here, and self retains the block, that's bad m'kay bugs. Thanks Tom Davie ___ 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/diederik%40tenhorses.com This email sent to diede...@tenhorses.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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: I don't agree, blocks are very powerful. I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings when a block reference to a property caused a retain cycle. This is how I found it and why I mentioned it in another thread in the first place. I haven't tested it extensively, but it looks as if the compiler recognises these situations easily and then tells you about it. So I wouldn't call blocks dangerous at all… You're right – the compiler *is* detecting some simple cases, as I suggested! Note – this does not make throwing blocks around without paying attention to retain cycles inherently safe though, the compiler can not statically infer all potential cycles. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
The compiler indeed warns, but only for ARC projects, and for non-ARC projects it perfectly allows blocks to create retain cycles without any warnings, even Xcode's Analyze doesn't help. Besides, I'm afraid the compiler is not always capable to detect all such dangerous situations even with ARC on. So I am afraid it ends up with lots of retain cycles in virtually every project that uses blocks, but programmers just don't notice and/or just don't care. Do you often check your projects for leaks of this kind? You will be surprised if you do try. My point remains: blocks are dangerous and there is no easy way to ensure they are safe. You can't avoid referencing self in blocks, because it is the very point of almost every callback block. So you have to every time to remind yourself to jump through hoops to avoid the retain cycles. Nah. On Thu, Apr 25, 2013 at 1:45 PM, Tom Davie tom.da...@gmail.com wrote: On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: I don't agree, blocks are very powerful. I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings when a block reference to a property caused a retain cycle. This is how I found it and why I mentioned it in another thread in the first place. I haven't tested it extensively, but it looks as if the compiler recognises these situations easily and then tells you about it. So I wouldn't call blocks dangerous at all… You're right – the compiler *is* detecting some simple cases, as I suggested! Note – this does not make throwing blocks around without paying attention to retain cycles inherently safe though, the compiler can not statically infer all potential cycles. Thanks Tom Davie ___ 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
sandboxd deny hid-control weirdness
I am writing a program that I hope to get into the App Store. During testing, all went well - no errors, no crashes, nothing to be concerned about. Having Archived it, and exported a Developer ID-signed Application (for further testing), I find myself facing a rather annoying problem. My program still works correctly (no crashes or problems of that nature), but the console is showing the following error on a regular basis: 25/04/2013 13:02:06.100 sandboxd[701]: ([458]) DeviceInfo(458) deny hid-control How can I track down what is causing this 'deny hid-control' error? The full report leaves me none the wiser: DeviceInfo(458) deny hid-control Process: DeviceInfo [458] Path:/Applications/DeviceInfo.app/Contents/MacOS/DeviceInfo Load Address:0x1 Identifier: com.paxsoftware.DeviceInfo Version: 1 (1.0) Code Type: x86_64 (Native) Parent Process: launchd [178] Date/Time: 2013-04-25 13:02:06.093 +0100 OS Version: Mac OS X 10.8.3 (12D78) Report Version: 8 Thread 0: 0 libsystem_kernel.dylib 0x7fff98e9e686 mach_msg_trap + 10 1 CoreGraphics0x7fff954ed259 _CGSPostEventRecord + 201 2 CoreGraphics0x7fff956b1494 encode_event_record_for_posting + 42 3 CoreGraphics0x7fff9530d645 CGSEncodeEventRecord + 117 4 CoreGraphics0x7fff956b1458 CGSPostEventRecord + 657 5 Ink 0x7fff96373f01 -[InkClientSideEvent repostCGEventToCGConnection:markAsReposted:] + 155 6 Ink 0x7fff96364dc7 -[InkContext dispatchQueuedEvent:withDisposition:andRepostType:isFinalDispatch:] + 472 7 Ink 0x7fff96364ad0 -[InkContext metaDispatch:triggerEventDisposition:] + 560 8 Ink 0x7fff963645eb -[InkContext inspectEvent:] + 929 9 Ink 0x7fff96363145 _InkInspectCarbonEvent + 202 10 HIToolbox 0x7fff96d0431e InkPreflight + 413 11 HIToolbox 0x7fff96cfbc8c AcquireEventFromQueue + 270 12 HIToolbox 0x7fff96cf1c77 ReceiveNextEventCommon + 393 13 HIToolbox 0x7fff96cf1ae3 BlockUntilNextEventMatchingListInMode + 62 14 AppKit 0x7fff8da9e563 _DPSNextEvent + 685 15 AppKit 0x7fff8da9de22 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 16 AppKit 0x7fff8da951d3 -[NSApplication run] + 517 17 AppKit 0x7fff8da39c06 NSApplicationMain + 869 18 DeviceInfo 0x00011db4 start + 52 Thread 1: 0 libsystem_kernel.dylib 0x7fff98ea0d16 kevent + 10 1 libdispatch.dylib 0x7fff9730e9ee _dispatch_mgr_thread + 54 Thread 2: 0 libsystem_kernel.dylib 0x7fff98e9e686 mach_msg_trap + 10 1 CoreFoundation 0x7fff91697233 __CFRunLoopServiceMachPort + 195 2 CoreFoundation 0x7fff9169c916 __CFRunLoopRun + 1078 3 CoreFoundation 0x7fff9169c0e2 CFRunLoopRunSpecific + 290 4 CoreFoundation 0x7fff916aadd1 CFRunLoopRun + 97 5 Foundation 0x7fff8fc4ccd2 __NSThread__main__ + 1345 6 libsystem_c.dylib 0x7fff8d24c7a2 _pthread_start + 327 7 libsystem_c.dylib 0x7fff8d2391e1 thread_start + 13 Thread 3: 0 libsystem_kernel.dylib 0x7fff98ea06d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x7fff8d24ed13 _pthread_wqthread + 412 2 libsystem_c.dylib 0x7fff8d2391d1 start_wqthread + 13 Thread 4: 0 libsystem_kernel.dylib 0x7fff98ea06d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x7fff8d24ed13 _pthread_wqthread + 412 2 libsystem_c.dylib 0x7fff8d2391d1 start_wqthread + 13 Binary Images: 0x1 -0x1cff7 com.paxsoftware.DeviceInfo (1.0 - 1) 543C3BAA-C385-3E8F-8F7B-6D9AA0B421D0 /Applications/DeviceInfo.app/Contents/MacOS/DeviceInfo 0x7fff8d238000 - 0x7fff8d304ff7 libsystem_c.dylib (825.26) 4C9EB006-FE1F-3F8F-8074-DFD94CF2CE7B /usr/lib/system/libsystem_c.dylib 0x7fff8d949000 - 0x7fff8e576ff7 com.apple.AppKit (6.8 - 1187.37) FAEA8B77-210F-3C0F-B9CF-85A7595CCA26 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff8fbb7000 - 0x7fff8ff14ff7 com.apple.Foundation (6.8 - 945.16) 89BD68FD-72C8-35C1-94C6-3A07F097C50D /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff91667000 - 0x7fff91851ff7 com.apple.CoreFoundation (6.8 - 744.18)
Re: Simple Vector Based Line Charts
So I was looking for a graphics library in the Developer Docs that serves both Mac-Apps and iOS-Apps. I found references to polylines in a MapKit. There is of course Quartz2D and OpenGL. So which of these libraries or perhaps there is another I have not heard of yet is best at building simple vector line charts? MPWDrawingContext is a wrapper for Quartz. Doesn't have chart drawing functionality, but makes things a little easier and more messaging-oriented. https://github.com/mpw/MPWDrawingContext http://blog.metaobject.com/2013/01/more-objective-c-drawing-context.html Maybe it can help. Marcel ___ 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: Simple Vector Based Line Charts
Have you looked at CorePlot ? Sent from my iPhone On 2013/04/25, at 22:50, Marcel Weiher marcel.wei...@gmail.com wrote: So I was looking for a graphics library in the Developer Docs that serves both Mac-Apps and iOS-Apps. I found references to polylines in a MapKit. There is of course Quartz2D and OpenGL. So which of these libraries or perhaps there is another I have not heard of yet is best at building simple vector line charts? MPWDrawingContext is a wrapper for Quartz. Doesn't have chart drawing functionality, but makes things a little easier and more messaging-oriented. https://github.com/mpw/MPWDrawingContext http://blog.metaobject.com/2013/01/more-objective-c-drawing-context.html Maybe it can help. Marcel ___ ___ 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: Simple Vector Based Line Charts
If you have quite simple requirements, a CAShapeLayer might work. You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can help with creating the CGPath if you don't want to drop to the CGPath API (no such luck on Mac - NSBezierPath can't be trivially converted to a CGPath AFAIK). The C-based CGPath API is not bad though. Jamie. On 10 Apr 2013, at 06:31, YT y...@redwoodcontent.com wrote: So I was looking for a graphics library in the Developer Docs that serves both Mac-Apps and iOS-Apps. I found references to polylines in a MapKit. There is of course Quartz2D and OpenGL. So which of these libraries or perhaps there is another I have not heard of yet is best at building simple vector line charts? YT ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.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
SMLoginItemSetEnabled ACL Problem
Forgive me for having two questions in flight at once. This is an entirely
separate issue - and this might not even be the right forum for it. I can't
find a sandbox / app store forum to ask though.
My app should be able to launch itself at start up - but the helper app doesn't
seem to work. In fact, it doesn't even launch! All I get is this error:
25/04/2013 12:53:33.376 xpcd[226]: (null): Code identity[pid:
273::com.PaxSoftware.DeviceInfoLoginHelperApp
(/Applications/DeviceInfo.app/Contents/Library/LoginItems/DeviceInfoLoginHelperApp.app)]
is not in ACL for container:
~/Library/Containers/com.PaxSoftware.DeviceInfoLoginHelperApp/Data -- allowing
access.
I haven't attached any source code because it's not getting as far as executing
anything. If anyone can suggest what I might look at (probably a plist, I'd
have thought - so I've included those settings), I'd be most grateful.
Plist:
Bundle identifier = com.PaxSoftware.${PRODUCT_NAME:rfc1034identifier}
Application is background only = true
The login helper App is included in the main app, and the code in the main app
seems to function correctly:
- (IBAction)autoLaunchChange:(id)sender
{
// Creating helper app complete URL
NSURL *url = [[NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]]
URLByAppendingPathComponent:
@Contents/Library/LoginItems/DeviceInfoLoginHelperApp.app];
// Registering helper app
if (LSRegisterURL((__bridge CFURLRef)url, true) != noErr)
{
NSLog(@LSRegisterURL failed!);
}
if (!SMLoginItemSetEnabled
((CFStringRef)@com.PaxSoftware.DeviceInfoLoginHelperApp, ([autoLaunch
state]==NSOnState)))
{
[
autoLaunch setState:NSOffState];
NSAlert *alert = [NSAlert alertWithMessageText:@An error occurred
defaultButton:@OK
alternateButton:nil
otherButton:nil
informativeTextWithFormat:@Couldn't set DeviceInfo Launch State.];
[alert runModal];
}
}
___
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: ^Block statement considered harmful for callbacks?
Using blocks with ARC just requires more discipline, that's all. It isn't to be avoided, just carefully thought about at the appropriate times. On Thu, Apr 25, 2013 at 6:07 AM, Oleg Krupnov oleg.krup...@gmail.comwrote: The compiler indeed warns, but only for ARC projects, and for non-ARC projects it perfectly allows blocks to create retain cycles without any warnings, even Xcode's Analyze doesn't help. Besides, I'm afraid the compiler is not always capable to detect all such dangerous situations even with ARC on. So I am afraid it ends up with lots of retain cycles in virtually every project that uses blocks, but programmers just don't notice and/or just don't care. Do you often check your projects for leaks of this kind? You will be surprised if you do try. My point remains: blocks are dangerous and there is no easy way to ensure they are safe. You can't avoid referencing self in blocks, because it is the very point of almost every callback block. So you have to every time to remind yourself to jump through hoops to avoid the retain cycles. Nah. On Thu, Apr 25, 2013 at 1:45 PM, Tom Davie tom.da...@gmail.com wrote: On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: I don't agree, blocks are very powerful. I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings when a block reference to a property caused a retain cycle. This is how I found it and why I mentioned it in another thread in the first place. I haven't tested it extensively, but it looks as if the compiler recognises these situations easily and then tells you about it. So I wouldn't call blocks dangerous at all… You're right – the compiler *is* detecting some simple cases, as I suggested! Note – this does not make throwing blocks around without paying attention to retain cycles inherently safe though, the compiler can not statically infer all potential cycles. Thanks Tom Davie ___ 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/sbdegutis%40gmail.com This email sent to sbdegu...@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: Temporarily disabling autosave
On 2013 Apr 24, at 11:38, Steve Mills smi...@makemusic.com wrote: Like the way TextEdit does it; you see the change take place, but then it instantly blinks back to the way it was before. It's *very* un-Mac-like and feels extremely half-baked. On the contrary, I would suspect that it has been fully baked through many long heated meetings and memos at Apple, selected as the least worst fix for this corner case in which the the Auto Save clashes with an old tradition, in this case WYSIWYG. I thought that NSBeep() was better for my app. Here is an excerpt from a newsletter I just received from Smile Software… PDFpen 6.0.2 is now available from Smile. This update includes an option to turn off autosave and versions. H. Two bug fixes after Autosave and Versions was adopted with great fanfare in 6.0.0. Indeed, there are some users, some documents, and maybe even some apps for which (Lion) Auto Save and Versions is not appropriate. Anyhow, I'm glad that you and your marketeers appear to have have thought this through and know what you're doing. ___ 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: Temporarily disabling autosave
On Apr 25, 2013, at 11:01:08, Jerry Krinock je...@ieee.org wrote: PDFpen 6.0.2 is now available from Smile. This update includes an option to turn off autosave and versions. Good. More apps need to offer that ability. H. Two bug fixes after Autosave and Versions was adopted with great fanfare in 6.0.0. Indeed, there are some users, some documents, and maybe even some apps for which (Lion) Auto Save and Versions is not appropriate. Anyhow, I'm glad that you and your marketeers appear to have have thought this through and know what you're doing. Saving in place is not something most users expect, because it hasn't been done that way on all the common platforms. I can't begin to count the number of times I've opened documents, edited them in some way, not intending to save those changes. Maybe I just needed to, say, find an image in a particular layer of some image editing app, so I hid some layers. That sort of thing. But doing something as simple as quitting means those changes will automatically change my actual document file without even asking if I want to discard them. That's just dangerous. What if some other app is using that file? The autosaved changes *to the actual file* will affect that other app. It's just a horrible idea. Autosave as loss prevention in the event of a crash? Good idea. Autosave to dumb down the user experience? Bad idea. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: ^Block statement considered harmful for callbacks?
On Apr 25, 2013, at 1:20 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
This breaks encapsulation of objects with block properties (e.g.
MyAnimation.completionBlock)
I understand the problem you're describing (and yes, I've had a couple of
memory leaks resulting from it) but I don't understand how you think it's
breaking encapsulation.
It seems to me that it's much better to drop the convenience of blocks
in favor of safety and full control of retain/assign relationships
between my objects.
It's a subjective decision, but for what it's worth, I disagree. Blocks are so
useful that it's not worth giving them up. In any case, you're talking about
only one use of blocks — as a way to tell an object an action to perform later,
a replacement for delegates or target/action pairs. There are plenty of other
good uses for blocks that don't have these issues.
In my code, most of the places I use a block as an onXXX property value it's
going to be called exactly once. What I do then is, in the caller, set the
corresponding _onXXX ivar to nil after calling through it, to break cycles.
- (void) xxxHappened {
if (_onXXX) {
_onXXX();
_onXXX = nil;
}
}
—Jens
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: Find functions disabled while NSSearchField is first responder.
On 24 Apr, 2013, at 21:46 , Antonio Nunes devli...@sintraworks.com wrote: I have an NSSearchField, and a menu bar submenu with the standard Find items. When the search field receives some input, it performs its action and an array controller is filled with search results. Now, while the search field is the first responder, none of the Find items are enabled, so it is impossible to issue, say a Find Next command. The Find functions perform fine when just about any other item in the document window is first responder. I find that surprising, but, more importantly, I cannot find a way to get the Find functions to work, while the search command has focus. What am I missing? I added a search field to a small test project, to see if it works correctly in a less complicated setup, but to no avail. The Find menu items are still disabled. Some more googling (previous queries did not yield any relevant info), showed me that this issue has bitten others before, but no solutions appear to have been put forward. I've checked the responder chain, and tried to catch calls to validateMenuItem and validateUserInterfaceItem:, to see if I can find out the point at which these items are disabled. But the break points don't even trigger. When I check the window for its first responder, when the search field is receiving input, it returns the document window, not the search field. The document window though, has its own implementation of validateMenuItem:, but that is never called. How can I find out where the validation for performFindPanelAction: fails? -António ___ 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: sandboxd deny hid-control weirdness
On Apr 25, 2013, at 7:10 AM, Pax 45rpmli...@googlemail.com wrote: I am writing a program that I hope to get into the App Store. During testing, all went well - no errors, no crashes, nothing to be concerned about. Having Archived it, and exported a Developer ID-signed Application (for further testing), I find myself facing a rather annoying problem. My program still works correctly (no crashes or problems of that nature), but the console is showing the following error on a regular basis: 25/04/2013 13:02:06.100 sandboxd[701]: ([458]) DeviceInfo(458) deny hid-control How can I track down what is causing this 'deny hid-control' error? The full report leaves me none the wiser: […] 8 Ink 0x7fff963645eb -[InkContext inspectEvent:] + 929 You've turned on Ink, and Ink is attempting to send HID events, which the sandbox is striking down. This is normal, and there is no workaround because Apple refuses to allow sandboxed apps to send HID events. In the past, using Ink also blocked sandboxed apps from receiving mouse-up events, though I think that bug has been fixed by now. Nick Zitzmann http://www.chronosnet.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: ^Block statement considered harmful for callbacks?
My point remains: blocks are dangerous and there is no easy way to
ensure they are safe. You can't avoid referencing self in blocks,
because it is the very point of almost every callback block. So you
have to every time to remind yourself to jump through hoops to avoid
the retain cycles. Nah.
Yes you can.
MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
^() = {
Foo *wself = [weakRef originalObject];
// wself may be nil, that's cool because we only want to doStuff if 'self' is
still around.
[wself doStuff];
}
___
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: Temporarily disabling autosave
On Apr 25, 2013, at 09:10 , Steve Mills smi...@makemusic.com wrote: Saving in place is not something most users expect, because it hasn't been done that way on all the common platforms. Uh, you can't make statements like that without citing evidence. Have you surveyed most users on this point? There are plenty of users to whom the idea of saving is itself unexpected -- because the [pre-Lion] need to save changes implied that your computer was otherwise going to discard your changes, and why would it do that For people with this mindset, needing to save explicitly is like some kind of punishment. I can't begin to count the number of times I've opened documents, edited them in some way, not intending to save those changes. Maybe I just needed to, say, find an image in a particular layer of some image editing app, so I hid some layers. That sort of thing. But doing something as simple as quitting means those changes will automatically change my actual document file without even asking if I want to discard them. That's just dangerous. You have this exactly backwards. Autosaving-in-place never changes the *saved* document file. It writes the autosaved document elsewhere. When you quit with an open, dirty document, there are two copies until you relaunch. At that point, your document is *still* dirty, and you can *still* close the document window explicitly, and you get a dialog asking if you want to save or discard changes (back to the point of the original save, which was before you quit and relaunched). Autosave-in-place was explicitly designed to avoid the problem you're complaining about! Remember, way back in this discussion, I said that the post-Lion saving behavior made sense only in its own terms, not in terms of the pre-Lion behavior. It sounds like your approach to this is stuck in pre-Lion terms, and so of course the new behavior seems wrong to you. ___ 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: Temporarily disabling autosave
On Apr 25, 2013, at 10:05 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: I can't begin to count the number of times I've opened documents, edited them in some way, not intending to save those changes. Maybe I just needed to, say, find an image in a particular layer of some image editing app, so I hid some layers. That sort of thing. But doing something as simple as quitting means those changes will automatically change my actual document file without even asking if I want to discard them. That's just dangerous. You have this exactly backwards. Autosaving-in-place never changes the *saved* document file. It writes the autosaved document elsewhere. When you quit with an open, dirty document, there are two copies until you relaunch. At that point, your document is *still* dirty, and you can *still* close the document window explicitly, and you get a dialog asking if you want to save or discard changes (back to the point of the original save, which was before you quit and relaunched). Actually no—autosaving-in-place means exactly that changes are always saved to the main document file, hence in place. There is only ever a single file per document, even when quitting. However, in Mountain Lion, we added preferences that allow you to (1) force documents to close on Quit, and (2) ask if the user wants to keep changes that they haven't explicitly saved (Cmd-S). In the above scenario, when these preferences are enabled, you will be given the option to discard all the experimental / temporary changes (made possible by Versions). -KP ___ 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: ^Block statement considered harmful for callbacks?
MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
^() = {
Foo *wself = [weakRef originalObject];
// wself may be nil, that's cool because we only want to doStuff if 'self'
is still around.
[wself doStuff];
}
How is that different from
__typeof__(self) __weak wself = self;
^() = {
[wself doStuff];
}
...or am I missing something from the beginning of the thread?
cheers,
Torsten
___
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: ^Block statement considered harmful for callbacks?
On Apr 25, 2013, at 9:54 AM, Lee Ann Rucker lruc...@vmware.com wrote:
MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
^() = {
Foo *wself = [weakRef originalObject];
// wself may be nil, that's cool because we only want to doStuff if 'self'
is still around.
[wself doStuff];
}
It's easier to just use the __weak attribute, if you're using ARC:
__weak Foo *weakRef = self;
^() = {
Foo *wself = weakRef;
// wself may be nil, that's cool because we only want to doStuff if
'self' is still around.
[wself doStuff];
}
Still, I think this is what Oleg called jumping through hoops. You and I just
don't think it's a very significant hoop :)
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ^Block statement considered harmful for callbacks?
Figured there must be something like that :) We have complicated reasons for
doing it with classes (C++ is involved) and since I'm at home hitting reload on
the WWDC ticket site I don't have the docs available.
- Original Message -
From: Torsten Curdt tcu...@vafer.org
To: Lee Ann Rucker lruc...@vmware.com
Cc: Oleg Krupnov oleg.krup...@gmail.com, Cocoa-Dev List
cocoa-dev@lists.apple.com
Sent: Thursday, April 25, 2013 10:27:14 AM
Subject: Re: ^Block statement considered harmful for callbacks?
MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
^() = {
Foo *wself = [weakRef originalObject];
// wself may be nil, that's cool because we only want to doStuff if 'self'
is still around.
[wself doStuff];
}
How is that different from
__typeof__(self) __weak wself = self;
^() = {
[wself doStuff];
}
...or am I missing something from the beginning of the thread?
cheers,
Torsten
___
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: ^Block statement considered harmful for callbacks?
It's easier to just use the __weak attribute, if you're using ARC: Ah, so that's when you get to use it. Well, a couple hundred files written over the course of 7 years isn't going to be ARC any time soon, nice as it might be. ___ 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: Temporarily disabling autosave
On Apr 25, 2013, at 10:21 , Kevin Perry kpe...@apple.com wrote: Actually no—autosaving-in-place means exactly that changes are always saved to the main document file, hence in place. There is only ever a single file per document, even when quitting. Oops, I obviously got too focused on the autosave elsewhere part of this. However, I think the essence of my point was correct. Without activating the options added in Mountain Lion, if you quit with a dirty document and relaunch, it comes back as a dirty document. You've neither lost nor gained anything by quitting. In fact, IIUC, even if you don't quit, a timed autosave will also save the document in place, right? You can still discard your changes, if you wish, which seems to be one of the worries Steve had. Steve also seems worried that autosaved changes are visible to other apps using the same document, but that's a design choice of the post-Lion document architecture, with the whole coordinator/presenter mechanism to support it. Steve might validly be worried about the privacy implications of this behavior, but it seems over-alarmist to call it dangerous or dumbed-down. ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 18:35, Lee Ann Rucker lruc...@vmware.com wrote: It's easier to just use the __weak attribute, if you're using ARC: Ah, so that's when you get to use it. Well, a couple hundred files written over the course of 7 years isn't going to be ARC any time soon, nice as it might be. Luckily, if you grab Landon Fuller's PLWeakCompatibility (and possibly Mike Ash's MAZeroingWeakRef too), you'll be able to use __weak in your non-arc code too. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
Yes, this is jumping through hoops, and even then you are not entirely safe.
How about referencing ivars from blocks? How about referencing other objects
that may in their turn reference self etc.? You have to keep it all in mind and
constantly fight with the side-effects by adding more crappy hoops to your
code. And it is a problem that does not even exist with delegates.
On Apr 25, 2013, at 8:29 PM, Jens Alfke j...@mooseyard.com wrote:
On Apr 25, 2013, at 9:54 AM, Lee Ann Rucker lruc...@vmware.com wrote:
MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
^() = {
Foo *wself = [weakRef originalObject];
// wself may be nil, that's cool because we only want to doStuff if 'self'
is still around.
[wself doStuff];
}
It's easier to just use the __weak attribute, if you're using ARC:
__weak Foo *weakRef = self;
^() = {
Foo *wself = weakRef;
// wself may be nil, that's cool because we only want to doStuff if
'self' is still around.
[wself doStuff];
}
Still, I think this is what Oleg called jumping through hoops. You and I
just don't think it's a very significant hoop :)
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 20:48, Oleg Krupnov oleg.krup...@gmail.com wrote: Yes, this is jumping through hoops, and even then you are not entirely safe. How about referencing ivars from blocks? How about referencing other objects that may in their turn reference self etc.? You have to keep it all in mind and constantly fight with the side-effects by adding more crappy hoops to your code. And it is a problem that does not even exist with delegates. On the other hand, delegates add the problem that they desiccate the code for dealing with the results from the code for setting up the request in the first place. I would consider that a much much much higher penalty than having to a bit careful about retain cycles. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
I understand the problem you're describing (and yes, I've had a couple of memory leaks resulting from it) but I don't understand how you think it's breaking encapsulation. The encapsulation is broken by the fact that you can't place whatever code you need in the callback block and have to always remember about internal implementation of blocks, and its possible implications and side effects, even for the simplest cases. It's definitely not something you'd want to focus on, given that blocks were called to make life easier, not harder. Implicit side-effects are always harder to track and debug. In my code, most of the places I use a block as an onXXX property value it's going to be called exactly once. What I do then is, in the caller, set the corresponding _onXXX ivar to nil after calling through it, to break cycles. I made it clear in the subject that I was talking about callbacks. There are perhaps a number of cases (iterators, threading) where blocks are not copied and seem to be perfectly fine. ___ 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: ^Block statement considered harmful for callbacks?
On the other hand, delegates add the problem that they desiccate the code for dealing with the results from the code for setting up the request in the first place. I would consider that a much much much higher penalty than having to a bit careful about retain cycles. You are correct, and that was why I switched ruthlessly to blocks instead of delegates for callbacks... Until I found this nasty problem with retain cycles, which doesn't actually have an elegant solution, and the workarounds leave ugly scars in your code and an uneasy feeling of suspicion to every line of your code in blocks. In fact, blocks only give you an illusion of all code in one place, but just as with delegates, it is dissected in time, and personally I always find it more difficult to read code with blocks, because it takes me an effort to understand the context the code will ge running in, across the block scope. Now if you add the necessity to think about retain cycles, it's pretty much a nightmare. After some time of using blocks, after their novelty worn off, personally I don't find them so much more convenient for callbacks as they initially seemed (even if there were no retain cycles, which are there, don't forget). It is not always relevant to place the callback code in the same place where I set up the worker object, and I often find myself calling a single method in the block that does the callback down the code, like I would do with delegates. Besides, it's quite tricky with blocks if you need to cancel the previous worker and replace it with a new one, whereas with delegates you can simply retain the current worker and compare it with the callback's sender. All in all I come to personally find delegates more elegant and honest than blocks for callbacks. Am I alone here? :) ___ 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: ^Block statement considered harmful for callbacks?
Hi Jens,
On Apr 25, 2013, at 18:10 , Jens Alfke j...@mooseyard.com wrote:
On Apr 25, 2013, at 1:20 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
This breaks encapsulation of objects with block properties (e.g.
MyAnimation.completionBlock)
I understand the problem you're describing (and yes, I've had a couple of
memory leaks resulting from it) but I don't understand how you think it's
breaking encapsulation.
Seems pretty obvious to me: blocks capture variables from their lexical scope
implicitly and then let them escape this scope. I explain this (briefly) in my
HOM paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4687
Sometimes that is exactly what you want, but often not. Especially for
multi-threading applications you want to explicitly control what you share, not
have it implicitly captured.
It seems to me that it's much better to drop the convenience of blocks
in favor of safety and full control of retain/assign relationships
between my objects.
It's a subjective decision, but for what it's worth, I disagree. Blocks are
so useful that it's not worth giving them up. In any case, you're talking
about only one use of blocks — as a way to tell an object an action to
perform later, a replacement for delegates or target/action pairs.
I'd agree that these are application areas that blocks are not really well
suited for. For processing something later, I do think the HOM approach is
simpler: [[self afterDelay:0.1] pollSearchResults];
Target-action also seems ill-suited to blocks, and IMHO if Objective-C had had
blocks at the time, IB would have been much less useful.
There are plenty of other good uses for blocks that don't have these issues.
Agreed! For example around processing. No more -lockFocus / unlockFocus,
gsave/grestore etc.
In my code, most of the places I use a block as an onXXX property value it's
going to be called exactly once. What I do then is, in the caller, set the
corresponding _onXXX ivar to nil after calling through it, to break cycles.
- (void) xxxHappened {
if (_onXXX) {
_onXXX();
_onXXX = nil;
}
}
Interesting. I can see how it works, not quite seeing how that would be a
common idiom...but curios!
Cheers,
Marcel
___
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: NSScrollView in NSTabView autolayout problem
I ran into a very similar problem. Recently, I put my view hierarchy into an NSTabView. When it's in the inactive tab, I get lots of Unable to simultaneously satisfy constraints errors. When the view hierarchy is in the active tab, there are no errors. I use auto layout in most of my views accept for the views in document.subviews in NSScrollView. I don't know if being in the inactive tab is exposing or causing auto layout problems. I suspect that it will be time consuming to track down. I'm not recommending this, but one less-than-ideal way to avoid the problem is to completely deconstruct the view hierarchy before it's in the inactive tab with code like this: [[self subviews] makeObjectsPerformSelector: @selector(removeFromSuperview)]; Then rebuild the view hierarchy before it's in the active tab. Chuck On 4/22/13 5:26 PM, kwic...@wichry.net kwic...@wichry.net wrote: Hello My problems persist. So the NSScrolView as such work perfectly if they are in the active tab view. However if another tabview is active while window resizing the scrollviews on the inactive tabs get crazy and report NSClipVIew constraint with width 0. Best K On 19 Apr 2013, at 08:37, Krzysztof Wicher wrote: Thank you Chuck for pointing me to the answer I will try that. I know that NSScrollView is not build with Autolayout in mind but I hoped using it would save several boring layout managment problems arising in my design. Also, I did send the message last week but as it was my first to this mailing list, I was not sure how long it take so I did not resend. Thanks again K On 18/04/2013 17:37, Chuck Soper wrote: This message may be relevant for your issue: http://prod.lists.apple.com/archives/cocoa-dev/2013/Feb/msg00426.html Personally, I don't use auto layout in NSScrollView. I think that NSScrollView doesn't support it, but it appears that many people have gotten it to work. Chuck P.S. It looks like your message was sent to the list on Saturday, but I didn't receive it until this morning. On 4/13/13 1:57 PM, kwic...@wichry.net kwic...@wichry.net wrote: Hi I have an NSTabView with multiple tabs, each containing an NSScrollView. In the scrollviews I dynamically place custom views which are sized using autolayout and constraints. Now if I add my custom views to a scrollview in tab1 and resize the window with this tab active everything works fine and autolayout does not complain. On the other hand, if I add my custom views to a scrollview in tab1, switch to another tab, resize the window, and switch back to tab1 autolayout breaks with the following exemplar message: Unable to simultaneously satisfy constraints: ( NSAutoresizingMaskLayoutConstraint:0x4011d8f60 h=-- v=-- H:|-(0)-[FlippedDocumentView:0x4011b76e0] (Names: '|':NSClipView:0x40120eb80 ), NSLayoutConstraint:0x4012a5c80 H:|-(10)-[TextViewModuleView:0x401236e80] (Names: '|':FlippedDocumentView:0x4011b76e0 ), NSLayoutConstraint:0x4011148e0 H:[TextViewModuleView:0x401236e80]-(10)-| (Names: '|':FlippedDocumentView:0x4011b76e0 ), NSAutoresizingMaskLayoutConstraint:0x4011d8f00 h=-- v=-- H:[FlippedDocumentView:0x4011b76e0]-(0)-| (Names: '|':NSClipView:0x40120eb80 ), NSAutoresizingMaskLayoutConstraint:0x4011d5e00 h=-- v=-- H:[NSClipView:0x40120eb80(0)] ) What I noticed in the message is this H:[NSClipView:0x40120eb80(0)]. How come the NSClipView so in fact contentView of the scrollview has width = 0? My question is, why does the autolayout work fine for the active tab and does for inactive? Thanks k. ___ 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/chucks%40veladg.com This email sent to chu...@veladg.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/chucks%40veladg.com This email sent to chu...@veladg.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: ^Block statement considered harmful for callbacks?
On Apr 25, 2013, at 1:32 PM, Oleg Krupnov wrote: All in all I come to personally find delegates more elegant and honest than blocks for callbacks. Am I alone here? :) Possibly. :) I always find it more difficult to read code with blocks, because it takes me an effort to understand the context the code will ge running in, across the block scope. Now if you add the necessity to think about retain cycles, it's pretty much a nightmare. I don't know… I don't have any trouble with it. Perhaps it's with how often you're using a particular pattern but I use blocks wherever appropriate and rrely run into a retain cycle, and the context/scope thought process seems trivial to me. I've only been skimming through this entire thread, but just to throw it out there, perhaps you could post a specific real-world use case where it's more trouble than it's worth; I'm thinking maybe you might be able to avoid the retain cycles etc by tweaking your interfaces rather than just thinking about memory management. I know one (of the only two I can think of) cases where I had a retain cycle in a block, I ended up tweaking the interface for an unrelated reason and it worked that retain cycle right out as a side effect. *shrug* Just a thought. -- Seth Willits ___ 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
More constraints confusion
I put an NSImageView into a window. I want the NSImageView's frame to always fill the window content frame. When I dropped it in, IB gave it a width and height constraint that I can't edit. I sized it to fit the window, and it also added leading and trailing space constraints. I explicitly set top and bottom constraints. But the width height constraints can't be edited. If I promote them to user constraints, and then try to delete them, they just come back. Why does IB think they are necessary? -- Rick ___ 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: More constraints confusion
No, pinning is not what I want. That's what I'm trying to avoid. IB in insisting on pinning the width and the height. I think it assumes the NSImageWell MUST have a static size, rather than allow it to resize. I'm able to put an NSView without this problem. On Apr 25, 2013, at 16:48 , Caylan Larson i...@caylan.net wrote: Rick, Search the help menu for pin and see if pinning the height or width gets you to where you need to be. Caylan On Apr 25, 2013, at 6:39 PM, Rick Mann rm...@latencyzero.com wrote: I put an NSImageView into a window. I want the NSImageView's frame to always fill the window content frame. When I dropped it in, IB gave it a width and height constraint that I can't edit. I sized it to fit the window, and it also added leading and trailing space constraints. I explicitly set top and bottom constraints. But the width height constraints can't be edited. If I promote them to user constraints, and then try to delete them, they just come back. Why does IB think they are necessary? -- Rick ___ 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/i%40caylan.net This email sent to i...@caylan.net -- Rick ___ 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: Simple Vector Based Line Charts
On 26/04/2013, at 12:07 AM, James Montgomerie ja...@montgomerie.net wrote: If you have quite simple requirements, a CAShapeLayer might work. I found that CAShapeLayer is not very good when it is scaled up significantly, e.g. in a view that gets zoomed by more than 4x or so. It depends on its size - because the path is always rendered in screen space, the size of the tile needed can quickly exceed the limits of OpenGL. This is a severe limitation if you plan to use CAShapeLayer for a vector composition that you plan to make zoomable. You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can help with creating the CGPath if you don't want to drop to the CGPath API (no such luck on Mac - NSBezierPath can't be trivially converted to a CGPath AFAIK). The C-based CGPath API is not bad though. Converting a NSBezierPath to a CGPath is easy - just iterate over the elements and call the appropriate CGPath methods. Going the other way is harder, as it requires that you set up a callback for CGPathApply. Using the Core Graphics API directly (maybe embedded in classes of your own device) is likely to be the most portable and fastest method for rendering vector graphics. --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: More constraints confusion
IB adds constraints to both the NSImageView and its superview. I believe that this is why deleting a constraint causes it to come back (it's in two views). Here's what I recommend: - Delete the NSImageView which will also delete the associated constraints. - Drag a new NSImageView to the window (i.e. the main view of the window). - Resize the NSImageView to fit inside the frame of its containing view. - Select NSImageView, by double clicking on the NSImageView in the list of objects. Now, from the Editor menu select Align - Horizontal Center in Container and Align - Vertical Center in Container. (You can also do that by clicking on the leftmost icon of the constraints control at the bottom right of the IB view.) That should do it. Adding those alignment constraints deleted the trailing and bottom constraints. Chuck On 4/25/13 4:39 PM, Rick Mann rm...@latencyzero.com wrote: I put an NSImageView into a window. I want the NSImageView's frame to always fill the window content frame. When I dropped it in, IB gave it a width and height constraint that I can't edit. I sized it to fit the window, and it also added leading and trailing space constraints. I explicitly set top and bottom constraints. But the width height constraints can't be edited. If I promote them to user constraints, and then try to delete them, they just come back. Why does IB think they are necessary? -- Rick ___ 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/chucks%40veladg.com This email sent to chu...@veladg.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: More constraints confusion
On Apr 25, 2013, at 6:50 PM, Rick Mann rm...@latencyzero.com wrote: No, pinning is not what I want. That's what I'm trying to avoid. IB in insisting on pinning the width and the height. I think it assumes the NSImageWell MUST have a static size, rather than allow it to resize. I'm able to put an NSView without this problem. Pinning *is* what you want. Do each of Pin Leading/Trailing/Top/Bottom Edge To Superview, and then the height and width constraints should become deletable. If it still won't let you delete them even after that, then just give them a low enough priority in the Inspector that they cease to matter. 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: More constraints confusion
On Apr 25, 2013, at 18:30 , Charles Srstka cocoa...@charlessoft.com wrote: Pinning *is* what you want. Do each of Pin Leading/Trailing/Top/Bottom Edge To Superview, and then the height and width constraints should become deletable. Sorry, I misunderstood. Yes, I had already pinned the Leading/Trailing/Top/Bottom Edges To Superview. If it still won't let you delete them even after that, then just give them a low enough priority in the Inspector that they cease to matter. Like I said, I think this is something about Image Well (NSImageView). In its size inspector, it has three pre-defined sizes in a popup. I think IB is trying to require that it be of fixed size. I finally just gave up and wrote code to stick my image into the CALayer of an NSView, which does not exhibit this behavior in IB. -- Rick ___ 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: More constraints confusion
On Apr 25, 2013, at 8:35 PM, Rick Mann rm...@latencyzero.com wrote: On Apr 25, 2013, at 18:30 , Charles Srstka cocoa...@charlessoft.com wrote: Pinning *is* what you want. Do each of Pin Leading/Trailing/Top/Bottom Edge To Superview, and then the height and width constraints should become deletable. Sorry, I misunderstood. Yes, I had already pinned the Leading/Trailing/Top/Bottom Edges To Superview. Perhaps try it again. IB can be a little wonky sometimes WRT constraints; perhaps re-adding the constraints for the four edges to the superview again, and see if it makes IB realize that the height/width constraints aren't needed. If it still won't let you delete them even after that, then just give them a low enough priority in the Inspector that they cease to matter. Like I said, I think this is something about Image Well (NSImageView). In its size inspector, it has three pre-defined sizes in a popup. I think IB is trying to require that it be of fixed size. I finally just gave up and wrote code to stick my image into the CALayer of an NSView, which does not exhibit this behavior in IB. I tried it myself in IB with an NSImageView after reading your original post, and was not able to reproduce this behavior, so that's not it. 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: More constraints confusion
On 4/25/13 6:35 PM, Rick Mann rm...@latencyzero.com wrote: On Apr 25, 2013, at 18:30 , Charles Srstka cocoa...@charlessoft.com wrote: Pinning *is* what you want. Do each of Pin Leading/Trailing/Top/Bottom Edge To Superview, and then the height and width constraints should become deletable. Sorry, I misunderstood. Yes, I had already pinned the Leading/Trailing/Top/Bottom Edges To Superview. If it still won't let you delete them even after that, then just give them a low enough priority in the Inspector that they cease to matter. Like I said, I think this is something about Image Well (NSImageView). In its size inspector, it has three pre-defined sizes in a popup. I think IB is trying to require that it be of fixed size. I finally just gave up and wrote code to stick my image into the CALayer of an NSView, which does not exhibit this behavior in IB. This would happen if you had the Image Cell selected instead of the Image Well. If you shift-control click on the IB object that you're trying to select, you'll get a popup menu. Make sure that you select Image Well not Image Cell. Chuck ___ 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
