Sad to say, it seems that you're in a common position of not understanding the basic structure of a GUI program. In its simplest form, it looks like this:
main (){
wait_for_events_and_timeouts ();
if (redraws_requested) {
do_redraw ();
}
}
}
finalize_stuff ();}
you need to refactor your code so that either your menu handlers do not take so long or you execute them in a different thread, and then use an idle handler to queue a redraw in any relevant widgets when they are done (queuing an idle handler is the one and only GTK-related thing you can do from the other thread(s)).
On Wed, Feb 15, 2017 at 11:30 PM, Thomas Dineen <tdineen@xxxxxxxxxxxxx> wrote:
Gentle People:
I have a rather large project in progress based on the GTK2/Cairo packages.
Which brings me to the following question about gtk_widget_queue_draw:
For each Menu Function, meaning a C function, which is called by a menu event handle,
in response to a Menu Selection. I place a gtk_widget_queue_draw at the end of the function
to cause the screen to update in response to the command. Learned behavior from examples
and experience. This seems to work great.
Now the question: If the menu function is complex, requiring seconds or minutes to execute
the screen freezes or if windows are moved fails to update and we are left with a default
grey screen. Is there any way to cause a queue draw and screen up date from within this
long latency function.
My experience indicates that calling gtk_widget_queue_draw from within this long latency
function dose not cause a screen update.
Thomas Dineen
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
