Re: User dialog within a callback function

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> > Don't use more gtk_main loops, only the main loop,
> > and do everything else with callbacks, doing otherwise
> > is looking for trouble.

> I created a program that opens a file dialog on the first
> callback, the second callback is called when the dialog
> okay button is pressed.  Inside the second callback I
> run a loop that loads items into a ctree.  The ctree is
> frozen and I run a dialog that displays a status bar.  The
> only way I could get the status bar to update was to
> run gtk_main_loop_interation_do (whatever it is called).

> You say not to do a main loop in a callback, but how can
> I get the status bar to update otherwise?  Also, if the
> main loop iteration does not go then if the windows are
> messed with or killed then they will not respond to the
> signals.

If you think your solution is technically good, great, 
by all means use it! Don't interpret my words as a dogma,
what I am saying is, try to use gtk/glib main loops as less
as possible, don't be afraid to have several different callbacks
to handle each independent task. Copying from Havoc's book, pg 130:

"Typically you want to go a step further by waiting for the user to click
one of the dialog buttons without setting up a lot of callbacks. In GTK+
this is done by running a second instance of gtk_main (), entering another,
nested event loop. When the second loop exits, the flow of control returns
to just after your gtk_main () call. However, there are a host of complications
and race conditions, due to the large number of ways to close a dialog."

And here is exactly where the fun begins, say for example your nasty
user decides to press the Delete button in the window decorations while the
second loop is up and running: even if your windows were all modal, the 
user can still access the window decorations. Now, you have this nice 
confirmation dialog that should come up evertyme delete_event is 
triggered, obviously outside the second loop... so where are we now, 
in the first or in the second gtk loop? the confirmation dialog might
run only after leaving the second loop, but what
happens if there is no confirmation box and the dialog should be killed
at once? most likely you will end up in a totally unstable situation
because when the task done in the second loop ends, the first dialog
might not be there anymore...

Sure, you can block the "delete_event" while the second loop is up,
you can setup some kind of semaphores, etc...
According to Havoc's book, there are solutions, as gnome_dialog_run () 
and gnome_dialog_run_and_close (), but why shall we go into all this 
nightmare in the first place? just to have less callbacks?

Specifically regarding your comment about the progress bar,
you are probably right and I may be wrong, anyway just consider
this text also taken from Havoc's book, pg 64:

"Sometimes you want to process a few events without handling the flow
of control to gtk_main (). You can perform a single iteration of the
main loop by calling gtk_main_iteration (). This might process a single
event, for example; it depends on what tasks are pending. You can check 
whether any events need to be processed by calling the gtk_events_pending() 
predicate. Together, these two functions allow you to temporarily return 
control to GTK+ so that the GUI can "catch up". For example, during a
long computation, you will want to display a progress bar; you must
allow the GTK+ main loop to run periodically so that GTK+ can redraw
the progress bar. Use this code:
            while (gtk_events_pending ())
              gtk_main_iteration ();"

Is this what you are doing? this is not a second GTK loop, so
I don't see problems here, you just go outside the computational
loop to the single main gtk loop, take care of the events queue,
and back again.

Carlos