Progress bar animations?

[Vishal Rao]

On 1 February 2010 01:03, Hugo Pereira Da Costa <hugo at oxygen-icons.org> wrote:
> Hi Vishal,
> I am on the kwin list (so I recieved the other emails), and on
> kde-core-devel (which is were following emails should go). I have not yet
> watched at the code but have a couple of questions (besides the fact that I
> second Thomas comments):
>
> 1/ how does it work when an application sets increased of the progress bar 5
> % at a time. Does it really take 1 second to go X to X+5% ? For progress
> bars things usually work as following: an app requests an increment of 5 or
> 10%, then stays iddle for an unknown time, the request the next increment.
> The only place where I think you can animate is between the moment where you
> get the request and the moment at which the requested value is actually
> shown on screen (which must be a _short_ time after, in order not to
> conflict with the next request. As result in such cases I don't think it is
> possible to have something smooth all the way from 0 to 100% (mostly because
> the requests from the applications are not smooth, and have to be honored in
> order not to defeat the purpose of the progress bar). Or did I miss
> something ?
>
> 2/ going  backward: it was pointed out when I committed the current
> animation code, that applications set the progressbar to 0 most of the time,
> not to indicate the notion of _reverse_ progress (from 100% to 0%) but
> rather as a "reset" before starting the next process. In such cases the
> going backward must _not_ be implemented: the progressbar must go immediatly
> to 0 and start again from there, animated.
> The way around that that we used in oxygen is to not animate _at all_ the
> progressbar when requested value is smaller than the current. I could not
> come with a more correct solution (because apps do not always reset to 0 but
> sometime reset to their first increment directly. Say for 100 to 10, or
> sometime 100 to 90. This is the case notably in konqueror progressbars.
>
> 3/ finally, when progressbars have identical min and max values set to zero
> it means that it should be animated as a "busy" indicator rather than a
> progress. In oxygen this is a small cursor going left to right and back at a
> slow pace. This must be kept, or it will be a regression.
>
> This said, I'll go through your code as soon as I am done with today's
> oxygen bugs :-)
>
> Hugo
>

My mistake, I will continue on kde-core-devel, I hope the email thread isn't too
noisy for the busy devs...

Yes, Hugo, thats what I meant by "the patch has extreme caveats/cheats" :-)

Yes good point, if its just 5% "distance" then I should dynamically adjust the
animation to be shorter duration.

OK, I agree "going backwards" should not animate.

Yes, with current QtProgressBar setValue/valueChanged it "conflicts" with
user initiated changes against animation controlled changes so with this
sample patch is user app again attempts to set/change value while
animation is in progress it will get lost/ignored! Not ideal I know.

What do you think about my concern that there may be a need for a
"KProgressBar" (or
send patches to Qt to extend QProgressBar) to properly support better/smoother
animation without limitations to avoid these severs problems? Or is my
understanding
of KDE/Qt code still too little/weak at this point?

Thanks for reminding about "busy indicator" I will test/watch for that
so no regression.

The rough patch is here: http://pastebin.ubuntu.com/366236/
Another video clip: http://www.youtube.com/watch?v=xp2aFgtN2No

Note that I am not trying to push my code changes into KDE. This is
more a learning
experience for me and thanks for taking the time off your busy
schedule to sort of mentor me!
If my emails/patches at least provide some ideas for proper
implementation so that I as a
user can enjoy smooth animations everywhere in KDE (for 4.5) then my
goal has been met.

Regards,
Vishal