Re: [gtk-list] Re: GtkProgressBar && RE: updating a progress bar

[Tim Janik <timj gimp org>]

On 5 Mar 1998, Tom Tromey wrote:

> Some lessons learned from Tk:
> 
> In Tk, all redraws (and some other things, like geometry computations)
> are done by idle handlers.  If you want to force a refresh, you have
> to call "update idletasks".
> 
> The problem with this is that it is too coarse-grained.
> 
> I was saw a suggestion that Tk be extended so you could write:
> 
> 	update idletasks {
> 	   some code here
> 	}
> 
> This would cause any idle handlers in the embedded code to be run --
> but no others.  The win here is that you'd have precise control over
> which tasks ran immediately.
> 
> 
> I bring this up because, while updating the progress bar immediately
> will probably solve the problem at hand, it doesn't really help with
> the more general problem.
> 
> For instance, suppose the progress bar shows percentage done of a
> copy, and there is also a label showing the current file being copied.
> Updating the progress bar isn't enough -- you also want to update the
> file name.

you actually require gtk to exactly know what aou want to have updated
in this case, which it oviusly can't tell.
sane application programs would devote time to gtk by calling its
main loop via gtk_main_iteration() which will also keep track of
redrawing caused by manual window resizeing or opaque window moves
done by the user during the copy.
if you really want to have only the label and the progress bar updated
and want this specific task done immediately, you should call
gtk_widget_draw(progress_bar, NULL);
gtk_widget_draw(label, NULL);

(this reminds me that widgets which are redrawn because of a
gtk_widget_draw(,NULL) should actually be removed from the redraw queue).

> 
> A more general approach to background tasks would enable this kind of
> control.
> 
> 
> This probably shows my gross ignorance of how Gtk works internally.
> But hopefully it will be helpful nonetheless.
> 
> Tom
> 

---
ciaoTJ