100

Another motion dynamics request (other is for scrollbars)

This time I'm suggesting implementing smooth acceleration/deceleration between progress bar positions.

Right now it appears that if an app sets progressbar percent say 50% then suddenly sets it to 75% next, the progress bar jerkily jumps from 50 to 75.

The idea is for the underlying progressbar widget to send additional position events/steps with smooth acceleration then deceleration so the bar moves smoothly from 50% to 75%, see what I'm trying to say? This will make even misbehaving apps (those that dont set small increments of progress) look much smoother too. Plus if implemented in the core lib then all existing styles/themes like Oxygen/QtCurve will automagically gain this smoothness without each author having to add motion dynamics code themselves.

We must admit/accept that the Windows 7 progress bar has this smooth movement and gives a polished high quality feel to the UI

If this is not possible without hardware acceleration then this could be maybe a KWin desktop effect which enables only if supported...

not voting down but i'd want to disable this feature system-wide in system settings if it gets implemented

why ?

i want to see the true state of the system at all times including when its not visually pleasing. if an application jumped from 50 to 75 i want to see exactly this in the progress bar and in real-time

i also dont want the extra cpu load caused by this feature

I like the concept of a smooth progress bar. I have been using the Ubuntu Smooth usplash, till it stopped working in jaunty.
https://launchpad.net/~usplash-smooth/+archive

Although yes, keeping such features as optional might be a good idea, since not all may want an extra eyecandy.

So this is calculus, right? Determine a rate of change for the progress bar and then animate the bar based on that? Seems like an awesome idea, although it seems that if the progress bar is smokin' along, and then halts dead at, say, 50%, there wouldn't be enough time for deceleration, and the bar would overshoot it's target.

So here's what I propose: Assume the above scenerio happens, and the progress bar shoots past 50%... then I propose that it continue along, but lapse like the shore on a beach, fading away to leave behind everything up to the 50% mark... I think it would be pretty.

ash wrote:i also dont want the extra cpu load caused by this feature

With all due respect, you're using KDE... A feature like this is awesome because of how simple it is, and how little extra CPU load it would add. This is pretty much the silliest worry to have when your entire desktop interface is a bunch of dynamically drawn SVG applets and your window manager is 3D accelerated with dropshadows by default.

The KDE 4.4 roadmap is looking good and includes use of QT Kinetic! So I'm hoping this brainstorm request will come to fruition soon

See http://aseigo.blogspot.com/2009/07/plas ... de-44.html

Well since I was bored this weekend, downloaded QtCreator IDE and the Qt library sources and compiled on my home desktop. Then wrote a simple Qt dialog app with a progress bar and buttons to shift the bar.

Result: http://www.youtube.com/watch?v=x_GmgFVVCuM

Then I modified Qt's qprogressbar.cpp and rebuild the library (no modification to the dialog app) and added some crude animation (can't to real motion dynamics just yet haha) to try to make some bling.

Result: http://www.youtube.com/watch?v=uLV6OEwb32Q

You can see the quick-n-dirty modified QProgressBar::setValue() code in the background heh.

But anyways KDE 4.4 should have this stuff with Qt Kinetic so I'm hoping and looking forward to it

vishalrao wrote:Well since I was bored this weekend, downloaded QtCreator IDE and the Qt library sources and compiled on my home desktop. Then wrote a simple Qt dialog app with a progress bar and buttons to shift the bar.

Result: http://www.youtube.com/watch?v=x_GmgFVVCuM

Then I modified Qt\'s qprogressbar.cpp and rebuild the library (no modification to the dialog app) and added some crude animation (can\'t to real motion dynamics just yet haha) to try to make some bling.

Result: http://www.youtube.com/watch?v=uLV6OEwb32Q

You can see the quick-n-dirty modified QProgressBar::setValue() code in the background heh.

But anyways KDE 4.4 should have this stuff with Qt Kinetic so I\'m hoping and looking forward to it

It is an improvement and probably belongs in KDElibs somewhere... If you\'re bored again in a couple of months think about it

jospoortvliet wrote:It is an improvement and probably belongs in KDElibs somewhere... If you\'re bored again in a couple of months think about it

I'd rather patch QProgressBar directly, instead of creating a KProgressBar, which would be IMO the only option for a kdelibs-hosted solution.