> None of this makes any sense, other than the build-transitions being one > level deeper in the hierarchy than the side transitions. >
You're right. As I read the documentation over and over again it didn't make any sense to me at all. First I thought it's the language, since my mother tongue is german. But that was not the case. After a long time of "trial & error" I got it all working.. The different uses of the word "key" is horrible. Joachim Am 17.11.2009 um 18:05 schrieb Gordon Apple: > Here's the current status. I seem to have everything working, partly > due to you guys. Thanks. However, now having analyzed this thing to death, > I'm filing a bug report. > > First a summary of the (extended) problem. The view is layer hosted. > Its layer has a sublayer called "content", which has sublayers, one of which > is A, which is to be transitioned to B. This is akin to a > PowerPoint/Keynote slide transition. Layers A and B also have sublayers, > A1, A2, etc., which transition in al la "build" in PP. > > According to the docs, using [content addAnimation:trans > forKey:kCATransition] should have worked for slide transitions. It didn't. > However, using the delegate method, augmented by an ivar enable flag, did > work. > > Next, tried the delegate method for builds. Didn't work. It > transitioned in the entire layer stack (all sublayers of A or B) instead of > the single inserted layer. So I went back to using [B addAnimation:trans > forKey:kCAOnOrderIn] for builds. That worked properly. > > None of this makes any sense, other than the build-transitions being one > level deeper in the hierarchy than the side transitions. > > > Definition of "software development": A series of experiments, > hopefully culminating in the desired result. > > > On 11/16/09 2:02 PM, "cocoa-dev-requ...@lists.apple.com" > <cocoa-dev-requ...@lists.apple.com> wrote: > >> >> On Mon, Nov 16, 2009 at 11:01 AM, Matt Neuburg <m...@tidbits.com> wrote: >>> Nothing here "runs contrary to the documentation." We're now talking apples >>> and oranges. The "key" used in addAnimation:forKey: (such as kCATransition) >>> has nothing whatever to do with the "key" that arrives in >>> actionForLayer:forKey:. They both happen to be called "key" but that's all. >>> The former, as I explained in my previous message, is just an arbitrary >>> name, which is used just in case you need to call removeAnimationForKey: >>> later, and for no other purpose. The latter is the name of a CALayer >>> animatable property; that property is changing, and you are now being asked >>> whether to animate that property. >> >> You have it backwards. kCATransition is documented to be sent as the >> action identifier to -actionForLayer:forKey: whenever the sublayer >> tree changes. Instead, CA is only sending @"sublayers". This is >> incorrect. > > > > _______________________________________________ > > 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/cocoa-dev%40deelen.de > > This email sent to cocoa-...@deelen.de > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
