Re: [Tile-dev] Progress bars

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

On Fri, 25 Feb 2005, Joe English wrote:

>>> And if so, would a 'step' method be useful for indeterminate
>>> progress bars, where [$w step] is equivalent to:
>>>
>>>     $w configure -value [expr {[$w cget -value] + [$w cget -stepsize]}]
>>
>> [$w step] is cleaner.

Would step take an optional argument for the step size?  What's the 
default increment given that the current default range is 0-1?  Or would 
you make the default step 1, and change the default range to be 0-100?  Or 
add a -stepsize option?

> It occurs to me that there is no reason for -from to ever
> be anything other than 0; we could replace -from and -to
> with a single -maximum option.

Mmm... I could probably think of a reason (though perhaps an artificial 
one): suppose you had a listbox of a bunch of records or files you wanted 
to do something on a selection for that takes some time.  One might set 
their range to the minimum and maximum list index.

Of course, it would undoubtedly be better to set the maximum to the number 
of items selected, so it's certainly not a compelling reason.

> I kind of like muonics approach:

Credit where due, it was Pat's idea, though he suggested also having 
-value != 0 be part of the rule that turns on the barber pole.  That's not 
possible without lifting the cap, however, and that cap may be there for a 
good reason (if none other than so that each theme doesn't have to do its 
own capping to not draw more than necessary).

> We could just hardcode this -- pick a value and say "indeterminate
> progress bars complete one cycle each time the value increments by 100"
> or something like that.  But for now I'm inclined to use a "-mode"
> option.

To do that the cap that forces -from <= -value <= -to will have to be 
lifted.

--
Michael Kirkham
www.muonics.com