I think I should clarify that my proposal is not to remove any (working)
functionality from animators, just to regularize the naming, and make it so
that attributes behave normally (i.e., when you set `x`, you can read the value
back from `x`, and you will get an `onx` event). As it stands today, in
animators (despite what the documentation says), setting `start` will not
change the value of the `start` attribute (it will change the value of the
`started` attribute) and it will not send the `onstart` event (that event will
_eventually_ be sent, when the animator actually does start). Oh, and should
you try to _read_ the start attribute, it will always be true, no matter what
you may have set it to!
The least perturbation would be to deprecate the attribute `start` and use the
attribute `started` instead.
On 2010-03-08, at 15:56, Max Carlson wrote:
> I propose we change 'started' (meaning the animation is running) to 'running'
> because it's more clear. Otherwise, this looks great to me!
'running' is not really accurate and doesn't match the tense of most of our
other "active" attributes, which seem to be predominantly past participles
(locked, proxied, enabled, applied, paused) or adjectives (visible, clickable,
selectable). If we're going to change this, I would propose either `enabled`
or `runnable` as the attribute.
There are two things we should consider if we are renaming:
1) this attribute should convey that turning it off and back on _re_starts the
animation at the beginning, it does not pause the animation.
2) this attribute only permits the animator to run, it does not indicate that
the animator is actively "in motion".
If we need an attribute that conveys "in motion", then we should keep
`isactive` (perhaps renaming it to `running`?), and we should make it a full
attribute (as currently implemented, you can listen for `onisactive` but you
will never get an event).
> On 3/8/10 12:14 PM, P T Withington wrote:
>> <animatorgroup> (and hence<animator>) have some complexities in their API
>> that I would like to clean up in 5.0:
>>
>> Attributes:
>>
>> + `start`: is effectively write-only and collides with the event `onstart`
>> which it only indirectly effects.
>>
>> The value of `start` is currently stored in the attribute `started`, but if
>> you change the value of `started` it will _not_ have the same effect as
>> changing `start`.
>>
>> I propose we deprecate `start` and replace it with `started` (or perhaps,
>> since we are changing it, use a more descriptive term like `autostart`); in
>> a subsequent release we can remove `start` altogether as an attribute.
>>
>> + `isactive`: should have been a private attribute
>>
>> I propose that it be deprecated and made private in a subsequent release.
>>
>>
>> Methods:
>>
>> `doStart` => `setAttribute('started', true)`
>> `stop` => `setAttribute('started', false)`
>>
>> If we choose a different name for `started`, obviously that would be applied
>> here.
>>
>> I propose that these methods be deprecated and made private in a subsequent
>> release.
>>
>>
>> Events:
>>
>> It seems it would also be nice if we could have the tense of the events
>> agree. We currently have `onstart`, `onpaused`, `onstop`. If we don't use
>> `started` as an attribute, we could make these be `onstarted`, `onpaused`,
>> and `onstopped`. But perhaps that is going too far?
>>
>>
>> Your comments solicited.
>>
>> _______________________________________________
>> Diamond mailing list
>> [email protected]
>> https://hedwig.laszlosystems.com/mailman/listinfo/diamond
