Overlapping sibling views
Hi, I had to design my whole view system to work around the problems with overlapping sibling views not being guaranteed to be drawn in a specific order, but today I came across some posts that suggested that this was no longer the case. In the current 10.8 documentation it still says: Note: For performance reasons, Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. But in this thread from 2009, two Apple engineers (Corbin Dunn and David Duncan) said that the documentation is out of date, and that it should work as of 10.5: http://www.cocoabuilder.com/archive/cocoa/228191-nsview-behaves-different-on-10-4-vs-10-5.html There are conflicting views expressed in http://stackoverflow.com/questions/466297/is-there-a-proper-way-to-handle-overlapping-nsview-siblings My scenario is a whole lot of sibling, potentially translucent, overlapping, layer backed views. I'm fairly sure I tested this and found it to fail in mid 2010, so this would make it 10.6. It also appears that the CocoaSlides example app uses sibling views for the slides, and that appears to show the slides in the same order every time. So, is the problem actually fixed? And if so, what version of the operating system introduced the fix? Regards Gideon ___ 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: Overlapping sibling views
The docs are out of date. Overlapping views work properly as of 10.5 (albeit you might run into performance problems if you push it too far). Please use the feedback thing on the bottom of the docs to let Apple know it's wrong! On 30 Apr 2013, at 08:39, Gideon King gid...@novamind.com wrote: Hi, I had to design my whole view system to work around the problems with overlapping sibling views not being guaranteed to be drawn in a specific order, but today I came across some posts that suggested that this was no longer the case. In the current 10.8 documentation it still says: Note: For performance reasons, Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. But in this thread from 2009, two Apple engineers (Corbin Dunn and David Duncan) said that the documentation is out of date, and that it should work as of 10.5: http://www.cocoabuilder.com/archive/cocoa/228191-nsview-behaves-different-on-10-4-vs-10-5.html There are conflicting views expressed in http://stackoverflow.com/questions/466297/is-there-a-proper-way-to-handle-overlapping-nsview-siblings My scenario is a whole lot of sibling, potentially translucent, overlapping, layer backed views. I'm fairly sure I tested this and found it to fail in mid 2010, so this would make it 10.6. It also appears that the CocoaSlides example app uses sibling views for the slides, and that appears to show the slides in the same order every time. So, is the problem actually fixed? And if so, what version of the operating system introduced the fix? Regards Gideon ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Overlapping sibling views
On Apr 30, 2013, at 00:39 , Gideon King gid...@novamind.com wrote: My scenario is a whole lot of sibling, potentially translucent, overlapping, layer backed views. I've never seen any evidence that sibling *NSView*s draw in the wrong order since 10.5. I believe that 'drawRect:' is correctly called in the back-to-front order of the sibling arrangement in the parent view. However, I *have* seen firsthand, in the last few weeks, that the layers of siblings under a layer-backed parent view were composited in a random order. In my case, I had two sibling views, and I observed the bottom one displaying on top unpredictably, about 50% of the time. To be clear, the layers didn't get re-ordered randomly every time they were drawn. The random order was baked into the view or layer hierarchy as part of the view initialization, and didn't change subsequently as long as the view existed. So from my own experience, I'd agree there is a problem, but I don't know where the problem lies. It may be nothing to do with layers. Perhaps there's currently a bug loading nibs that randomly re-orders sibling views. Perhaps the sibling order in the layer hierarchy doesn't match the order in the view hierarchy. Perhaps the hierarchies are correct but the layer compositing operation is wrong. ___ 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: Overlapping sibling views
I've never seen any evidence that sibling *NSView*s draw in the wrong order since 10.5. I believe that 'drawRect:' is correctly called in the back-to-front order of the sibling arrangement in the parent view. However, I *have* seen firsthand, in the last few weeks, that the layers of siblings under a layer-backed parent view were composited in a random order. In my case, I had two sibling views, and I observed the bottom one displaying on top unpredictably, about 50% of the time. Sorry for stepping in, but I have seen this behavior as well in the last week … I had this in the tree ... - NSView - NSView (layer backed for AVPlayer) - NSButton … and NSButton was invisible - to be more precise, this button wasn't drawn in correct order, but it did work = I was able to click on it. This invisibility was random. To fix correct drawing order, I had to set wantsLayer = YES on the root NSView as well. And then it was fixed and no more random invisibility. R. ___ 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: Overlapping sibling views
On 30 Apr 2013, at 09:38, Robert Vojta rob...@tapmates.com wrote: I've never seen any evidence that sibling *NSView*s draw in the wrong order since 10.5. I believe that 'drawRect:' is correctly called in the back-to-front order of the sibling arrangement in the parent view. However, I *have* seen firsthand, in the last few weeks, that the layers of siblings under a layer-backed parent view were composited in a random order. In my case, I had two sibling views, and I observed the bottom one displaying on top unpredictably, about 50% of the time. Sorry for stepping in, but I have seen this behavior as well in the last week … I had this in the tree ... - NSView - NSView (layer backed for AVPlayer) - NSButton … and NSButton was invisible - to be more precise, this button wasn't drawn in correct order, but it did work = I was able to click on it. This invisibility was random. To fix correct drawing order, I had to set wantsLayer = YES on the root NSView as well. And then it was fixed and no more random invisibility. Layer-backed views always *appear* above non-layer-backed views. Effectively, all non-layer-backed views get rendered into a single layer that makes up the entire window. ___ 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: Overlapping sibling views
On Tuesday, 30. April 2013 at 10:42, Mike Abdullah wrote: Layer-backed views always *appear* above non-layer-backed views. Effectively, all non-layer-backed views get rendered into a single layer that makes up the entire window. Thanks, didn't know this. Never needed layer backed view until now because of AVPlayer ... ___ 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: Overlapping sibling views
So it sounds as if as long as I have all my views in the entire hierarchy layer backed, my sibling views should always draw in order. This makes me happy :) … and the documentation wrong :( - I'll report that. Regards Gideon ___ 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: Overlapping sibling views
On 30 Apr 2013, at 16:53, Gideon King gid...@novamind.com wrote: So it sounds as if as long as I have all my views in the entire hierarchy layer backed, my sibling views should always draw in order. Yup. Bear in mind WebViews don't support being layer-backed (still!), which can throw a spanner in the works. ___ 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: Overlapping sibling views
On Tue, 30 Apr 2013 01:30:00 -0700, Quincey Morris said: On Apr 30, 2013, at 00:39 , Gideon King gid...@novamind.com wrote: My scenario is a whole lot of sibling, potentially translucent, overlapping, layer backed views. I've never seen any evidence that sibling *NSView*s draw in the wrong order since 10.5. I believe that 'drawRect:' is correctly called in the back-to-front order of the sibling arrangement in the parent view. However, I *have* seen firsthand, in the last few weeks, that the layers of siblings under a layer-backed parent view were composited in a random order. I've seen that too, you can reference: rdar://11852080 Overlapping NSViews draw in wrong order when layer hosting/backing is involved Duplicate/10348980 and: rdar://11805856 'View Programming Guide' doc incorrect about overlapping views My workaround is: // For some reason the views don't draw in the right order unless we give them a little kick. rdar://11852080 id subviewsCache = [[[self stageHolderView1] subviews] copy]; [[self stageHolderView1] setSubviews:subviewsCache]; The bug dates from 10.7 and will presumably never be fixed, like most everything in Radar. Sorry, can't help it. :) Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Overlapping sibling views
On Apr 30, 2013, at 08:55 , Mike Abdullah cocoa...@mikeabdullah.net wrote: On 30 Apr 2013, at 16:53, Gideon King gid...@novamind.com wrote: So it sounds as if as long as I have all my views in the entire hierarchy layer backed, my sibling views should always draw in order. Yup. Bear in mind WebViews don't support being layer-backed (still!), which can throw a spanner in the works. Nope. I just tried it again, setting the layer-backed checkboxes all the way up in IB, and it still fails sometimes (about 1 time out of every 20 or 30, today). ___ 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: Overlapping sibling views
How did you test it? Did you sort the views at all, or just leave them in the order they were instantiated? Did you try Sean's workaround? Regards Gideon On 01/05/2013, at 4:39 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Nope. I just tried it again, setting the layer-backed checkboxes all the way up in IB, and it still fails sometimes (about 1 time out of every 20 or 30, today). ___ 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: Overlapping sibling views
On Apr 30, 2013, at 18:37 , Gideon King gid...@novamind.com wrote: How did you test it? Did you sort the views at all, or just leave them in the order they were instantiated? My hierarchy is very simple. The content view contains a single view (which layer-backed in order to use a background color), and that view contains two child views whose order is set in IB. I made no programmatic adjustments to anything. The only change from my original attempt was to make all of the views layer-backed in IB. Both child views are custom views, and they both return NO for isOpaque. I did, however, verify that the order of the child views was correct and hadn't been inadvertently switched somewhere in nib loading. The view order was correct. Did you try Sean's workaround? No, but I have no doubt it works as he says. ___ 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
Undocumented Leopard support for overlapping sibling views
According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html , http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html ) still says: Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. And Interface Builder 3.1 on the one hand has options like Layout Send to Front that change the ordering of subviews, yet on the other still warns about Illegal geometry when a view overlaps one of its siblings even when the deployment target is set to 10.5. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 1:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html,http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html ) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html ) still says: Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. And Interface Builder 3.1 on the one hand has options like Layout Send to Front that change the ordering of subviews, yet on the other still warns about Illegal geometry when a view overlaps one of its siblings even when the deployment target is set to 10.5. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? Hello, Please file a couple of bug reports on this: http://developer.apple.com/bugreporter/ Thanks! j o a r ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 3:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html , http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html ) still says: Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. And Interface Builder 3.1 on the one hand has options like Layout Send to Front that change the ordering of subviews, yet on the other still warns about Illegal geometry when a view overlaps one of its siblings even when the deployment target is set to 10.5. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? I believe that Apple relaxed the rules to allow CoreAnimation layers to work correctly. Whether or non a non-layered UI fully supports overlapping sibling views, I do not know. I just tried a test in IB. Warnings show up on overlapping views whether or not views are marked as needing a CA layer. I believe that is a bug. For the apps I'm writing, I do not yet use layers. For all views, I never overlap them (using the subview approach instead). Once I introduce layers, I will allow those particular views to overlap. The rest of the UI will continue to not overlap. One final thing to consider is that you may also suffer some performance hits when things overlap; especially for custom views where you do all the drawing. If your drawRect, e.g., always draws everything regardless of what is actually dirty, you would then redraw that whole thing if an overlapped view is marked dirty. Even if they only overlap by a single pixel/point. ___ Ricky A. Sharp mailto:[EMAIL PROTECTED] Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 3:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/ cocoa-dev/2007/Nov/msg01760.html, http://lists.apple.com/archives/ cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). Interesting. I hadn't noticed that discussion. I'm glad you brought it to my attention. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? I'd be interested in knowing that, too. Especially, I'd be curious to know how such support works when drawing outside of drawRect: using the lockFocus... methods, including by a secondary thread. Off to file a documentation bug... Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 5:09 PM, Ken Thomases wrote: On Aug 28, 2008, at 3:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html , http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). Interesting. I hadn't noticed that discussion. I'm glad you brought it to my attention. [...] Off to file a documentation bug... The NSView class reference says: addSubview: Adds a view to the receiver’s subviews so it’s displayed above its siblings. [...] addSubview:positioned:relativeTo: Inserts a view among the receiver’s subviews so it’s displayed immediately above or below another view. I don't remember if the z-ordering was documented as guaranteed before. I just submitted feedback using the link at the bottom of the NSView class reference: The docs for -addSubview and -addSubview:positioned:relativeTo: should make clear that z-ordering is only guaranteed starting in 10.5 (unless it was really guaranteed all along but you couldn't be sure it always would be). --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 2:40 PM, Corbin Dunn wrote: Please do log bugs requesting the documentation to be enhanced. Overlapping views do work in Leopard+, with or without layers. However, a sibling layered view will always be on top of a sibling non-layered view. I will do so, as well as a bug against Interface Builder for suppressing geometry warnings on platform(s) that support overlapping views. One further clarification, is the top view for drawing always the top view for event handling, especially with regards to layered/non- layered? How does -[NSView hitTest:] behave when multiple subviews are under a given point? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 4:46 PM, Andy Lee wrote: On Aug 28, 2008, at 5:09 PM, Ken Thomases wrote: On Aug 28, 2008, at 3:28 PM, Nathan Vander Wilt wrote: According to two list postings (http://lists.apple.com/archives/ cocoa-dev/2007/Nov/msg01760.html, http://lists.apple.com/archives/ cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). Interesting. I hadn't noticed that discussion. I'm glad you brought it to my attention. [...] Off to file a documentation bug... The NSView class reference says: addSubview: Adds a view to the receiver’s subviews so it’s displayed above its siblings. [...] addSubview:positioned:relativeTo: Inserts a view among the receiver’s subviews so it’s displayed immediately above or below another view. I don't remember if the z-ordering was documented as guaranteed before. It was. I have a Tiger system with the old docs and those quotes were present -- and coexisted with the warnings that overlapping sibling views didn't guarantee correct clipping, invalidation, or drawing. And so I took that documentation for the addSubview:... methods to mean very little. ;) In other words, the z-order guarantee doesn't imply correctness of clipping, invalidation, or drawing. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
