gtk_events_pending() returns FALSE with events sti

I'm working on an application that has a start and stop button. These buttons block the UI, and for various reasons, I can't spawn a thread.

I've been showing a working screen when these buttons are pressed, using:

while (gtk_events_pending()) gtk_main_iteration();

which ensures that the working screen is loaded before the start/stop operations begin.

I've recently upgraded to GTK+ 3.8.6, and it seems that gtk_events_pending() is now broken. Now, sometimes the window shows, but the image in the window isn't there. Sometimes the window doesn't even show.

The function in question looks like:

gtk_widget_show(working_screen);
while (gtk_events_pending()) gtk_main_iteration();

long_running_blocking_function();

If I do something like:

int busy_wait = 0;
gtk_widget_show(working_screen);
while (gtk_events_pending() || busy_wait < 5) 
{
    gtk_main_iteration();
    if (!gtk_events_pending()) ++busy_wait;
}

long_running_blocking_function();

...it works fine. However, I know it's only a matter of time until the busy_wait needs to be longer so I'd like to find a better answer. Has anybody experienced this issue? Does anybody have any ideas about how I might work around it?

Try g_main_context_pending(NULL) and g_main_context_iteration(NULL,FALSE) instead of gtk_events_pending(), the later is deprecated.

It could be a timing issue that kicks in (it oculd be that your loop kicks in before any events are registered to the mainloop, and thus instantly exits) - but this is just wild guessing due to lack of code.

The break condition is also wrong, you do not want to exit as soon as all events are processed at a specific point of time, you want to continue until long-run-ops are done. That means you need to signal when your operation is done, check that flag in the loop you currently use and use blocking mode of the *_iteration(...)