[Tile-dev] Re: [ tktable-Patches-1144673 ] Supporting animated progress bars (aqua, mainly)

[Michael K. <mi...@mu...>]

> Comment By: Joe English (jenglish)
> Date: 2005-02-21 09:51
>
> This feature is definitely a good idea, and the programmatic
> interface seems reasonable (if I'm reading the patch right
> -- the progressbar automagically animates whenever the
> -value is between -from and -to noninclusive, if the current
> theme supports it, right?)

Yes.  It only generates the timer events if it's between -from and -to, 
noninclusive.  It should also cancel any pending timer event if you do a 
call to set which sets it outside the range.  Right now, it basically 
always schedules the next update for <theme's delay> since the last one - 
whether that update came from a set or through a timer event.

> A couple design issues:  should there be explicit widget
> commands to start and stop the animation instead?  I
> normally don't like magic DWIM behavior, but the one above
> seems like it will always do the right thing.

I didn't see a way to pass information down from the general widget to 
where the it's drawn in the theme.  That's part of the reason that the 
phase period is hard coded in aquaTheme.c rather than using the theme 
setting (which controls how often WidgetChanged notifications happen). 
There would need to be a way to do that to turn on/off animation, though I 
don't think turning it on and off programattically is necessary exactly 
(more below).

> There's an unwritten Tile policy that things like autorepeat
> delays and cursor blink rates are set on a system-wide basis
> instead of on a per-widget or per-theme basis.  (Actually,
> the current policy is that these things are just hardcoded
> to something hopefully reasonable, but the eventual intent
> is to allow end-users to control them globally).  Anyway, I
> think the animation refresh rate falls into this category.

I don't know that I agree, but I don't have enough information to 
disagree.  I haven't seen a lot of animated progress bars or barber poles 
other than on the mac, but my gut tells me it'd be a poor assumption that 
all of them animate with the same number of frames and same speed.  If one 
uses 5 frames where Aqua uses 4, and it's a hard coded delay, then it's 
Tile's may look right but animate slowly compared to other applications; 
or if it uses 2 it will animate really fast.

I don't really like that I hardcoded the phase period in aquaTheme.c, 
though; things get really weird if you change the theme's WidgetChanged 
notification period to not match the hard-coded phase period.

But I also think that having them all update at once would cause
unnecessary updates (which could be a problem over X/Windows).  Either
you'll wind up redrawing when a "set" call is made and then very shortly
after redrawing again because the global timer came up, or you'll skip a
timer based update and the redraw might come too late.  Unless, for
animated progress bars, you never redraw on a "set" but only when the
timer dings.  But -then- the non-theme-specific progress bar code would
have to have knowledge of whether or not it's animated in the particular
theme, and it sounds messy.  (You don't want to redraw non-animated
progress bars as if they're animated under X/Windows.)

> More notes: we also need to support "indeterminate" (aka
> "barber-pole")  style progress bars as well as animation.
> I'm not sure what a good interface would be -- BWidgets
> supports this, but the API doesn't make much sense to me.

I think a simple widget configuration option would be fine, provided 
there's a way to get that option down to the draw routine.

> I kind of like how the Gtk progress bar works - there's a
> separate boolean option "activity_mode" that specifies
> determinate / indeterminate mode, and a "pulse" method that
> increments the value by a fixed amount (specified by the
> "pulse_step" option).

Relating to the start/stop command..  I don't think the animation should 
be tied directly to the Tcl script.  If it's required to pulse to redraw, 
then it will animate poorly if the resolution is too low.  The length of 
the progress bar should be the indicator of how far along it is, while the 
animation should only show the user that the application hasn't hung.

However, something that might be good as an alternative would be to have 
some sort of timeout.  Have it keep animating like it does now without any 
"set" calls, but if after 5-10 seconds (or some configurable setting) 
there have been no "set" calls then it can stop animating.  You'd want it 
long enough that the animation is smooth, but short enough that the script 
would need to say "I'm still alive" every now and then so the animation 
isn't lieing to the user.

> Another option would be to just let indeterminate progress
> bars spin on their own without any programmatic intervention
> (you can get this behaviour on Aqua with progressanim.patch
> by using kThemeIndeterminateBar instead of kThemeProgressBar).

I think either letting them spin freely or having a "keep-alive" timeout 
would be okay, but having the animation tied directly to "set" would be 
bad.  A keep-alive would be easy to cheat, though: if the application is 
not entering the event loop (which has to happen for animation to occur), 
pinging it isn't going to get the animation running.  If it is entering 
the event loop, then one could just send continuous
"after 100 ping_progress" calls that aren't tied in any way to the actual 
thing they're doing that the progress bar is supposed to reflect.  So it 
seems kind of pointless.  If the script falls into an infinite loop with 
no updates, the animation is going to stop whether there's some sort of 
keep-alive or not.  (That and the rest of the GUI.)

--
Michael Kirkham
www.muonics.com