Hi,
Thanks for your close consideration of my proposal. I've put some more comments
down below...
/Jonas
I agree that the Animation properties should not go out of sync with the
underlying objects.
personally, my take is that the Animation should:
- cache the values in case the Alpha and/or the Timeline instances
are not present, or if they are being replaced
- proxy the values otherwise
which is basically what are you proposing, except that I wouldn't remove
the loop, duration and mode variables from AnimationPrivate.
There is some confusion here involving the caching. The right way would be
either:
i) the variables are cached and used at object creation time,
or
ii) the objects are created when the variables are read/written and the values
are proxied.
What you have below is a mix of the two (explained below).
My preference is to proxy the values. Is there any advantage to caching them?
the behaviour of the Animation class would then match these invariants:
- set_mode()
+ no alpha set: create an alpha (without a timeline)
+ alpha set: set the mode
- set_duration():
+ no alpha set: create an alpha, then a timeline
+ alpha set: get the timeline of the alpha, set duration
- set_loop()
+ same as set_duration()
Here you create the objects when values are set... this has implications that
pretty much preclude caching the values, at all. By this, I mean the following:
set_{value} functions all create object and set value (this is my preferred
method). This has the following consequence on the following get_{value} functions:
- get_mode()
- get_duration()
- get_loop()
+ no alpha or no timeline are set: return the cached values
+ alpha or timeline set: return the alpha or timeline values
get_{value} functions return either:
i) proxied value if object exists (note that the object will always exist if
set_{value} has been called).
ii) or cached value if object does not exist, meaning that set_{value} has
never been called which implies that we always return "default" value here (i.e.
a constant)
My preference for ii) would be that we create the underlying objects here (with
"default" values) and proxy the return value... it's more consistent as we then
effectively always have case i).
for the set_alpha() and set_timeline() we need some more hand-holding,
because we depend on instances to make the animation machinery work:
- set_alpha():
+ no alpha set and passed NULL, create alpha (without a timeline)
+ no alpha set and passed !NULL, own the alpha and use its timeline
+ alpha set and passed NULL, create alpha and reuse the timeline
from the old alpha
+ alpha set and passed !NULL, own the alpha and use its timeline
I would go even further here:
+ no alpha set and passed NULL, do nothing
+ alpha set and passed NULL, unown the alpha
and...
- set_timeline()
+ no alpha set and passed NULL: create alpha and timeline using
stored values, and assign the timeline to the alpha
+ no alpha set and passed !NULL: create alpha and assign passed
timeline to the alpha
+ alpha set and passed NULL: create timeline using stored values
and assign it to the alpha
+ alpha set and passed !NULL: assign timeline to the alpha
...here...
+ no alpha set and passed NULL, do nothing
+ alpha set and passed NULL, set the alpha timeline to NULL which causes alpha
to unown timeline (but honestly, who would do this?)
The reason for this is that the user may want to "disconnect" his alpha from his
animation in order to use the alpha to drive something else without having the
animation run.
And... _get_timeline() does the job of creating the alpha and timeline if they
don't yet exist making the call to set_timeline/set_alpha with parameter NULL
superfluous.
Of course, the advantage that I see with you approach is compatibility with code
already written for 0.9... but the API is unstable, so this minor breakage
shouldn't be a big deal (the fix involves code removal... pretty easy).
What all of the above boils down to is the API effectively has two patterns:
_animation_new()
_set_mode()
_set_duration()
_set_loop()
get_timeline
and
_animation_new()
_set_alpha( EXTERNAL ALPHA )
_get_timeline
- get_alpha()
+ no alpha set: create an alpha using the stored values, with
no timeline
+ alpha set: return alpha
+no alpha set: create an alpha with "default" values and no timeline
- get_timeline()
+ return the timeline assigned to the alpha
+no alpha set: create alpha, create timeline, assign timeline to alpha,
return timeline
+alpha set: return timeline from alpha, creating it if necessary
in short: the Alpha should be available as soon as:
- :mode, :duration or :loop are set
- get_alpha() or get_timeline() are called
while the Timeline will be available as soon as:
- :duration or :loop are set
- get_timeline() is called
I'll document this properly before the 1.0 release.
thanks for your feedback!
Thanks for reading this far! :)
/Jonas
--
To unsubscribe send a mail to [email protected]
