Re: setUsesThreadedAnimation
Re: setUsesThreadedAnimation
- Subject: Re: setUsesThreadedAnimation
- From: Aki Inoue <email@hidden>
- Date: Fri, 31 May 2002 18:12:25 -0700
Richard,
Are determinate progress indicators considered "not animated" for the
purposes of the API? -- as opposed to indeterminate progress
indicators, which are animated. In this case, should I always
associate the word "animated" with an indeterminate progress
indicator? ... for example, if some selector works with an "animated
progress indicator" should I read that as "animated, indeterminate,
progress indicator?"
You're reading too much into the meaning between the lines 8-).
When we were developing Aqua (and thus the animating determinate
progress indicator), we could neither change the API nor compromise not
to animate. Existing apps had to automatically get the Aqua behavior
without requiring any modifications. You know, the existence of the UI
was secret. So, we had to change the threading behavior in determinate
progress indicators.
That much is a history now.
Will setUsesThreadedAnimation ever have any meaning for a determinate
progress indicator? Should I place this message in code, even if it
has no effect/does no harm now -- in the hopes that it might, one day,
work for determinate progress indicators?
I don't think that would ever happen. The threading support in the kit
has progressed greatly (compared to the old OPENSTEP days when this API
was first designed), it's actually much more efficient to use subthreads
for animations.
As regards indeterminate progress indicators, does the
setUsesThreadedAnimation message cause instances to animate using a
private thread? I'm just trying to understand what
setUsesThreadedAnimation does exactly ... is my theory right (that an
indeterminate NSProgressIndicator instance spawns its own thread to
animate when the setUsesThreadedAnimation message is sent)? I "think"
that this is what the documentation is saying, but I'm not sure.
Yes, all animating controls in the app (pulsating buttons and animating
progress indicators) share a single private subthread.
Aki
On 2002.05.31, at 17:14, Richard Kendall Wolf wrote:
On Friday, May 31, 2002, at 06:30 PM, Aki Inoue wrote:
\In the current implemenation, setUsesThreadedAnimation: has effect
only on indeterminate progress indicators.
Ahhhhh! Okay ... a couple of more questions, if I may ...
Are determinate progress indicators considered "not animated" for the
purposes of the API? -- as opposed to indeterminate progress
indicators, which are animated. In this case, should I always
associate the word "animated" with an indeterminate progress
indicator? ... for example, if some selector works with an "animated
progress indicator" should I read that as "animated, indeterminate,
progress indicator?" Will setUsesThreadedAnimation ever have any
meaning for a determinate progress indicator? Should I place this
message in code, even if it has no effect/does no harm now -- in the
hopes that it might, one day, work for determinate progress indicators?
As regards indeterminate progress indicators, does the
setUsesThreadedAnimation message cause instances to animate using a
private thread? I'm just trying to understand what
setUsesThreadedAnimation does exactly ... is my theory right (that an
indeterminate NSProgressIndicator instance spawns its own thread to
animate when the setUsesThreadedAnimation message is sent)? I "think"
that this is what the documentation is saying, but I'm not sure.
Thanks (again) in advance!
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.