Re: Update progress bar without returning to main loop?

[Bob Caryl <bob fis-cal com>]

Toralf Lund wrote:

> Foster Gareth wrote:
>
> > > Yes. Or that's the way I see it, anyway.
> > >
> > >   
> >
> >
> > http://bugzilla.gnome.org/show_bug.cgi?id=317424
> >
> >
> > Added new attachment that does it your way, or Bob's, there is a 
> > toggle to
> > choose.
>
> Great ;-)
>
> > Note that you can't quit out of the window while the processing is
> > taking place in your version, and the "go" button doesn't get 
> > redrawn. That
> > just serves to illustrate the differences though really.
> >  
>
> Yup. I think you may be able to get other widgets to be redrawn by 
> calling queue_redraw() *and* get_window()->process_updates() on each 
> of them, or just do it once and for all on the toplevel window, but I 
> haven't tried this. To be able to close the window, I guess you simply 
> have to remain sensitive to user input in general via the event loop.
>
> > Gaz
> > _______________________________________________
> > gtkmm-list mailing list
> > gtkmm-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
> >  
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
After modifying my code to use Gtk::Widget::get_window::process_updates 
instead of the way I was previously doing this, I find that the app is 
still not entirely insulated from user input.  If I press the close 
widget on my main window (or my progress bar window), the system will 
put up a dialog declaring the my application process is not responding 
and allow me to close it while my synchronus slow operation is still 
ongoing and the progress bar is progressing. 

At least it behaves this way using the Gnome desktop on the Suse 9.3 
flavor of linux.

Bob Caryl