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

main ()

   while (not_time_to_quit()) {

        wait_for_events_and_timeouts ();
        process_events_and_timeouts ();

        if (redraws_requested) {
              do_redraw ();

   finalize_stuff ();

your menu handlers execute as part of "process_events_and_timeouts ()". You
can see that if they take a long time, you are necessarily preventing the
program from reaching the "do_redraw()" stage.

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 <>

> 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 mailing list

Reply via email to