Bin Chen wrote:
>
> 在 2008-01-07一的 13:18 [EMAIL PROTECTED]
>> for(i=start_count;i<end_count;i++)
>> {
>> //g_print("i = (%d)\n",i);
>> while(j<100000)//To kill time, keep counting until a
>> lakh
>> j++;
>> j = 0;//Make j 0 for the next loop.
>> //sleep(2);
>> pdata->fraction = (gdouble)i/(gdouble)(range);
>>
>> fflush(NULL);
>> //gtk_progress_bar_pulse (GTK_PROGRESS_BAR
>> (pdata->pbar));
>> //gtk_progress_bar_set_pulse_step(GTK_PROGRESS_BAR
>> (pdata->pbar),pdata->fraction );
>> gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR
>> (pdata->pbar),
>> pdata->fraction);
>> }//End for i = start_count to end_count
>
> For this code snippet, you update all your progress in the loop and not
> yield the control to gtk_main(), this is the problem.
IOW you don't let gtk draw the UI until you are done with the button
callback. You should not block in the main gtk thread (the one where
you called gtk_main() from). Always return as fast as possible from
callbacks. Don't wait, don't block on anything.
> You should not write code like this, using a timer to update the
> progress bar instead of this loop, otherwise the drawing instruction
> will be pending due to your full control of CPU.
I suggest you use threads, they are easy to do with glib. When the
user clicks the button, create a thread and give it the progress bar
widget. In the thread do the loop and in ever iteration update the
progress bar. Pay attention to thread safety, use thread
synchronization primitives like mutexes (GMutex) when needed. I'm not
very familiar with gtk and threads, but IIRC gtk isn't thread safe by
default.
tom
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
