Re: [gtk-list] Re: non-exiting gtk_exit()

[Paul Barton-Davis <pbd op net>]

>This is a different question you are asking - you're asking how to
>make the outermost gtk_main() return. gtk_exit () has nothing to do
>with that, in fact returning from the outermost gtk_main() only
>conventionally quits the application, it hardly has to. 

precisely. if there is cleanup to be done after this return, where
should it be done ? yes, atexit() can be used, but thats ugly,
especially as Tomas has noted, the GTK thread has already been
terminated by GTK's own atexit()-registered function. Yikes. In my
code, that leads to a partially constructed C++ object. That hurts.

This bites me several times a day right now, and although no damage
results (we were in exit(), so things are pretty clean ...), its very
annoying.

>I would expect this to work:
> while (gtk_main_level () != 0)
>   gtk_main_quit ();
>
>but maybe it won't. 

correct, it doesn't. i am not sure why, but i was using it for a few
months and just putting up with the fact that it didn't work. Then I
switched to using gtk_exit() and atexit() to cleanup. It works
reliably, except for the problem Tomas has noted and I mentioned above.

		     Still, I would call this code broken; I'm not sure
>how it would behave if you had a modal dialog up, for example. A
>better solution is to never call gtk_main() recursively, and instead
>explicitly create a new GMainLoop and g_main_run()/g_main_quit() that
>main loop.

this seems a little perverse when a quick inspection of gtk_main() as
well as the various next-step-beyond-tutorial docs on GTK frequently
mention this nice ability to use it recursively. they don't happen to
mention that its a code motel: functions check in, but they can't
check out :)

--p