Re: GtkProgressBar && RE: updating a progress bar

[Owen Taylor <owt1 cornell edu>]

raster@redhat.com writes:

> On  5 Mar, Tony Gale shouted:
> ->  
> ->  On 05-Mar-98 Owen Taylor wrote:
> ->  > [ Maybe gtk_progress_bar_update should redraw itself instantly
> ->  > instead
> ->  >   of queuing a draw? ]
> ->  
> ->  Eek. That rather breaks the model [of GTK and other widget sets].

I wouldn't say it breaks the model - even currently, some things
in GTK (e.g., Text widget), for one reason or another, redraw
themselves instantly, instead of in a queued redraw.

I wasn't suggesting that the main loop be processed, just that
the drawing for that one widget should be done on screen immediately.

GTK, in fact, used to do all drawing immediately onscreen - this was
changed largely so that when multiple changes were made at once
it wasn't constantly redrawing everything.

(There is a current problem, that now events have absolute priority
over redrawing, so if you keep GTK busy with events, redrawing
will never happen)
 
> No - gtk currently breaks logic by not updating somehting that shoudl
> be re-drawn when updated.
> 
> If I - as a programmer am programming so I have a loop ant lest say
> scans a directory - and as I read I update the progress bar - I expect
> that progress bar to redraw and update when I update it - not 30 second
> slater do all the updates when I exit my function. GTK currently with
> this widget is defying logic. I believe Owen is right. This widget in
> particular needs to redraw when it is updated.

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

Regards,
                                        Owen