QProgressBar takes big steps

[Jayes]

Hi,

I have a progress bar that keeps pace with the time of an mp3 that is playing. The widget is just over 320 pixels wide and the range is set as (0, total), where "total" is the duration of the mp3 in seconds.

I can catch every second that has passed and set the value of the progress bar accordingly.

I would expect the bar to move 1 pixel per step (unless "total" is less than 320 seconds) but it moves 8 pixels at a time and simply waits until the elapsed time justifies such a big step. So even when the mp3 lasts 12 minutes the progress bar takes about 40 steps, each 8 pixels wide.

I looked for configuration options, but can't find anything relevant.

Any ideas on this?

Thanks,

JS

[wysota]

Maybe you are not allowing the event loop to process the events?

[Jayes]

I can output the elapsed time through prinf several times per second. Doesn't that mean the event loop is quick enough?

---

Added after 5 minutes:

Perhaps a few details can be of use:

I have subclassed the progress bar, but only to handle mouse events.
next:

ds_progress = new qm_clickprogressbar();
ds_progress->setFixedSize(324,8);
ds_progress->setMouseTracking(false);
ds_progress->setProperty("centerIndicator", QVariant(false));
ds_progress->setProperty("percentageVisible", QVariant(false));
ds_progress->setTextVisible(false);
ds_progress->setMinimum(0);

When I have the total time:

ds_progress->reset();
ds_progress->setRange(0,songTotalTime);

And when I get the current time :

ds_progress->setValue(curtime);

[wysota]

What is this qm_clickprogressbar class?

[high_flyer]

Does the percentage increase correctly?
It very well may be (but I don't know for sure) that the visual presentation for each step has a minimum of X pixels, since the purpose of the progress bar is to let the user know things are still running in the background, so usually a 1:1 visual representation of the current point of the range is not important.
You can test it by having a progress bar in a test application, where you connect lets say a slider to it.
There you can see exactly the "leaps" it will take not dependent of events.

[Jayes]

What is this qm_clickprogressbar class?

A subclassed QProgressBar:

lass qm_clickprogressbar : public QProgressBar
{
Q_OBJECT

public:
qm_clickprogressbar(QWidget *parent = 0);
virtual ~qm_clickprogressbar();

protected:
void mouseReleaseEvent ( QMouseEvent *e );
void mousePressEvent ( QMouseEvent *e );

signals:
void clicked();
void clicked(QMouseEvent *e);
void pressed();
void pressed(QMouseEvent *e);
void scrolled(int);
};

---

Added after 14 minutes:

Does the percentage increase correctly?

I have done this:

int timenow = function_to_get the_time( );
ds_progress->setValue(timenow);
printf ("Current Time: %i\n", timenow);
printf ("Progress Bar: %i\n", ds_progress->value());

The result is this:

Current Time: 1
Progress Bar: 1
Current Time: 2
Progress Bar: 2
Current Time: 3
Progress Bar: 3
Current Time: 4
Progress Bar: 4
Current Time: 5
Progress Bar: 5
Current Time: 6
Progress Bar: 6

Conclusion: The progress bar is set correctly, but it SHOWS only increments of 8 pixels.

[wysota]

What happens if you set the total progress to twice you have now? Will the bar update in steps of 4 pixels?

[Jayes]

What happens if you set the total progress to twice you have now? Will the bar update in steps of 4 pixels?

No, still 8 pixels. I just takes twice as long before the step is taken.

By the way ... I think is 8 pixels, but it could be 10. Maybe I can check with screen-dumps.

---

Added after 21 minutes:

I think is 8 pixels, but it could be 10.

I did. And I found both 9 and 10 pixel steps, possibly alternating. The total playing time of the song has no effect though.

[wysota]

Ok, second experiment. What if you make the progress bar twice as wide?

[Jayes]

Ok, second experiment. What if you make the progress bar twice as wide?

I can't. But I made it half as wide: Makes no difference (still 10 px steps).

I tried yet another experiment: I sent the code to a friend who runs Slackware (I run Debian testing). He compiled it and it works fine: 1 pixel per second. ... QT bug?

[wysota]

QT bug?

You'd have to ask Apple - Quick Time is their product

Run you application with arguments "-style Plastique" and see if it changes anything.

[Jayes]

Run you application with arguments "-style Plastique" and see if it changes anything.

Whoooo... bingo! That makes all the difference.
So it is a style bug. Perhaps related to the fact that I run my QT apps on Gnome. Out of my ballpark anyway.

Thanks for your hint!

JS

[wysota]

So it is a style bug.

It's not a bug, it's a feature.

[Jayes]

It's not a bug, it's a feature.

I'll be damned. You are right.
It is my Gtk theme and it behaves in the same way on Gtk apps.

Thanks again, and sorry to have bothered you with this.

JS

[Aiiaiiio]

Hi there!
I have the exact same use-case as mentioned here. Using plastique style is not a real solution I think since it messes up the system style (if you don't have everything customized).
I solved this by calling the progressbar's repaint() method every time it get's a new value.