Re: CALayer Transitions
Re: CALayer Transitions
- Subject: Re: CALayer Transitions
- From: Joachim Deelen <email@hidden>
- Date: Thu, 19 Nov 2009 16:56:37 +0100
> 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, "email@hidden"
> <email@hidden> wrote:
>
>>
>> On Mon, Nov 16, 2009 at 11:01 AM, Matt Neuburg <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden