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

[Tom Tromey <tromey creche cygnus com>]

Owen> I'm not so sure I'm right. I was just suggesting it as a
Owen> ease-of-use thing for the ProgressBar - but the programmer will
Owen> get better results if they process pending events in the event
Owen> queue periodically - for instance, Expose events won't be
Owen> handled otherwise.

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.

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