Re: GtkProgressBar ignoring gtk_widget_queue_draw()

[Owen Taylor <otaylor redhat com>]

Richard Stellingwerff wrote:
> Owen Taylor wrote:
>
> > Well, you are looking to do something awful anyways (call
> > gtk_widget_queue_draw() out of a theme engine), so given that, you
> > could investigate the further awfulness of doing:
> >
> >  GTK_PROGRESS_GET_CLASS(progressbar)->paint (GTK_PROGRESS(progressbar));
> >  gtk_widget_queue_draw (progressbar);
>
>
> After checking the source code, I noticed that the 
> gtk_progress_changed() function queues a resize using 
> gtk_widget_queue_resize(). Even though the size never changes, it does 
> seem to force a redraw. I did the same in my timer, and it works fine :)
>
> > I think you are going to run into the problem that apps frequently
> > put up a progress bar and only run the main loop occasioanlly to
> > update the progress bar when the application changes the value ...
> > that is, you aren't going to get a nice smooth animation.
>
>
> I've tried a bunch of applications so far, and the animation itself is 
> quite smooth. The code is in Clearlooks CVS right now, in case people 
> want to try it out. I am currently working on fixing RTL support (almost 
> done with that).

The GTK+ theme system has it's limitations, and themes that don't live
within those limitations *will* cause problems. Whether those problems
are inefficiency, instability, or incompatibility with non-GTK+ apps
that use the GTK+ theme system (like OpenOffice and Mozilla).

If you are just prototyping stuff out, seeing how it looks ... whatever
works. But for a theme that's going to be deployed onto user's systems,
adding timers, calling gtk_widget_queue_resize(), calling
gtk_widget_queue_draw() even are really bad ideas.

The only appropriate way to make progressbars animate in the current
GTK+ theme system is to submit a patch that adds a style property to
GtkProgressBar to enable that behavior and have GtkProgressBar handle
the timeouts and redraws.

Regards,
					Owen