Re: Return code for g_main_run/gtk_main

[Havoc Pennington <hp redhat com>]

Joe Shaw <joe ximian com> writes:
> 
> The usefulness is when you are blocking on something by using a recursive
> main loop, like gtk_dialog_run(), and you want to return some sort of
> status to the function that called the main loop. For GtkDialog, it seems
> to eliminate the need for the RunInfo struct.
> 
> In my example, I am doing an async file transfer that I need to block
> on. I have a signal that is called when the transfer is finished. So I run
> gtk_main() after starting the transfer and call gtk_main_quit() in the
> "file_done" callback. I would like to return a code via gtk_main_quit to
> tell me back in the original function whether or not the transfer
> succeeded.
> 
> The alternatives to this are either to make a struct like RunInfo in
> GtkDialog and passing in the address of a struct or having a global
> variable. Nothing too heavy, but handy nonetheless.

Sorry for the slow reply, all kinds of fun stuff going on.

I guess my feeling is that it isn't that useful, since it provides
such a limited piece of information. Even in the two cases you mention
here:

 - async file transfer; presumably you want more than just an exit
   code, say a user-readable error message? Or if you don't, 
   in general you might.

 - for the dialog_run() stuff, you do need the struct anyhow
   because you don't always replace the "default" return code
   (I think)

Anyway, the result of using this feature is code that has to be
rearranged a lot to make a small change. i.e. as soon as I want more
than an int.

I can imagine having some more general feature:

 gpointer data = g_main_loop_run ()

 and 

 g_main_loop_quit_with_data ()

But that seems to introduce memory management mess and just not be
very convenient.

Maybe others will disagree, though.

Havoc