Re: [Tile-dev] Progress bars

[Joe E. <jen...@fl...>]

Some more random thoughts:

 * * *

I see three main use cases for progress bars:

(1) the application knows exactly how much work is to be
done and the progress is shown proportionally;
(2) the application doesn't know how much work is to be done,
but can at least provide feedback about how fast it's going
(the "bouncing rectangle"); and
(3) the application just wants to show a throbber to keep
the user from thinking the program has locked up.

Sometimes a progess bar will start out in mode (2) or (3),
then switch to mode (1), so this should be configurable
by widget options; using separate -styles for determinate
and indeterminate progress bars isn't appropriate.

 * * *

Eric Boudaillier wrote:
> Joe English wrote:
> > Questions: Are the 'set' and 'get' methods really needed?
> > They're equivalent to [$w configure -value] and [$w cget -value],
> > respectively; or you can just access the linked -variable.
>
> Isn't there a general rule in tk that options are never changed
> internally, but only via configure subcommand ?
> This is at least what I have observed, with for example [entry].

That's not a hard and fast rule, but it does seem to
be the tendency; don't provide too many redundant equivalent
redundant ways of doing the same thing.

I'm inclined to drop [$w get] and [$w set].

> > 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.


You could also use [incr $linkedVar $amount], although having
a separate [$w step] method seems just useful enough to me
to warrant including it.  I'm inclined to add this one.


 * * *

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.

That would make the Tile progress bar nearly compatible with the
BWidget one; the main difference would be -mode vs. -type.
(And to be honest, I never really did understand the difference
between -type incremental, -type infinite, and -type
nonincremental_infinite, so this difference might be
a good thing :-)

 * * *

I kind of like muonics approach:

| Indeterminate mode is obtained by setting -from and -to both to 0.  As
| long as both have value 0, it will animate a barberpole.  Change either to
| non-zero and it will switch to a regular progress bar (showing just a
| track if the "set" value is <= -from).

(or, specify "-maximum 0" to get an indeterminate progress bar).
Except that, on most platforms indeterminate progress bars use a
"bouncing rectangle" effect instead of a "barberpole" effect.
This can be used to indicate how fast things are going, but
with '-maximum 0', the programmer doesn't know / can't control 
how much the bar will move when the -value is incrememented 
by a particular amount.

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.

 * * *

Anyway, new strawmanpage posted reflecting the above:

    <URL: http://tktable.sourceforge.net/tile/doc/progressbar.html >

This version is closer to BWidget's ProgressBar (good),
but, with the loss of -from, -to, and set, is completely
incompatible with the current ttk::progress widget (bad).

So I've changed the widget name to 'ttk::progressbar'.
If this ends up as the final version, we'll keep the
current [ttk::progress] widget around for one more
release cycle so early adopters will have a chance
to upgrade.


--Joe English

  jen...@fl...