Re: Progress bar help

[muppet <scott asofyet org>]

On Jan 20, 2006, at 11:05 AM, Daniel Davidson wrote:

> I am having trouble getting a progress bar to work properly.  I am
> preparing to write a backup program, but as of now I am just messing
> around.
>
> I can create the progress bar and I can make it so that whenever I  
> click
> a button, it increments toward 100% like it is supposed to.  However
> when I go and try to have the function automatically increment itself
> every second toward 100%, the bar does nothing until the function
> completes and it immediate jumps to 100%.  I am sure I am just missing
> something simple, what I think are relevant portions of code follow
> below.

This is the same basic principle behind "How do i keep my GUI  
updating during a long file read"[1], and there was a question about  
this same thing earlier this week[2].  Anyone want to volunteer a FAQ  
entry?

The problem is that your code does not allow the event loop to run.   
Nearly all gui updates, including those triggered by pulsing the  
progressbar, are handled in idles, which means the event loop must  
run or you see nothing.  Your code goes all the way to 100% before  
returning control to the event loop, so it appears that the  
progressbar does nothing.

The simple solution, as Aristotle pointed out, is to flush the event  
loop every time you bump the progressbar.  However, depending on how  
much work you in between, your program may become very unresponsive.   
The fix for that is

a) live with the sluggishness (often perfecfly ok for small apps, but  
can cause problems for things that are supposed to be cancelable)

b) break up your operation into small pieces on a work queue and  
handle the pieces in idles (the gimp does this; works well, but it is  
a lot of work)

c) fork and perform the work in a child process which writes progress  
information to stdout; then read this stdout from the parent to  
update the progressbar (at which point the "long file read" FAQ  
question becomes directly relevant).  Note:  do NOT attempt to mess  
with the gui from the child, or Bad Things will happen.

d) start a thread to do the work.  Threading and gtk2-perl don't get  
along very well for a variety of obscure reasons, so forking a child  
will be a lot less of a headache.

If you're interfacing with other programs, e.g. tar, then c) is  
usually the best option.


[1] http://live.gnome.org/ 
GTK2_2dPerl_2fFrequentlyAskedQuestions#head-3b88c68683fd189b09455a462d5e 
41669b7b1142

[2] http://mail.gnome.org/archives/gtk-perl-list/2006-January/ 
msg00066.html


> Can someone also explain to me what pluse does?  I think I know but  
> I am
> not sure.

http://developer.gnome.org/doc/API/2.0/gtk/GtkProgressBar.html#id2984380

This is basically the function you call to show that you're working,  
but that you don't know how much more you have to do.  If you know  
how much there is, don't use this; use set_fraction() instead.


--
However, like all drugs, PANEXA can produce some notable side  
effects, all of which are probably really, really terrific and  
nothing that anyone should be concerned about, let alone notify any  
medical regulatory commission about.
  -- http://www.panexa.com