Re: how to fully quit out of recursive main loops?

[Paul Davis <pbd Op Net>]

>I think you are just writing your code in a way no one else writes
>their code. ;-) Main loops are supposed to be orthogonal to one
>another. 

I don't write main loops. I do call gtk_main_run() recursively,
something that is/has been advertised as a nice feature of GTK+ (and
one I have generally enjoyed).

	  gtk_main_quit() doesn't "mean" exit the app, that's just 
>an interpretation specific apps can apply to it

I understand that. I'm using it only because I want to quit the GUI
(by returning control to the level that started the GUI).

>that extra loops will forbid quitting while they are running. I
>usually do the latter.

thats not a very nice policy, but yes, i suppose it would work.

>The number of GUI apps that want to shut down their GUI and never use
>it again is... pretty close to zero. And in the few exception cases,
>they can use multiple processes.

this is often indicative of poor program design. if i have a main that
does this:

	  ... create DSP objects ...
	  ... create MIDI objects ...
          ... create GTK objects ...
	  
	  ... start DSP ...
	  ... start MIDI ...
	  ... start GTK ...

	  /* the GUI is now running */

ok, now clean design would dictate that this be followed by:

	  /* GTK is done */

          ... stop MIDI ...
	  ... stop DSP ...
	  
	  ... destroy MIDI ...
	  ... destroy DSP ...

the MIDI and DSP objects have no relationship to GTK+, and should not
be coupled to GTK+ in any way. They may also need (or it may make the
user much happier if) the stop+destroy steps (are) carried out, rather
than just relying on the OS shutdown of file descriptors.

but because GTK offers no reliable way to get back to the point marked 

    /* GTK is done */

that can be hard to do. most programs don't bother with this cleanup,
because most programs don't use MVC programming, only use resources
for which the OS's automatic cleanup is adequate, and/or the
programmer just can't be bothered. in addition, there are very few
programs that use control methods other than the keyboard and mouse,
which GTK owns. this isn't adequate for the code i write, where i have
external MIDI (and USB and IEEE1394) controllers running the whole
thing as well as the keyboard and mouse. so yes, perhaps its a small
set of programs, but we're doing it the right way, and the rest of you
are just being lazy :)

even if i attach the stop+destroy steps to a loop quit (via
g_main_quit_add()), there i still no way for me to force the top level
GMainLoop to quit other than by keeping track of them (which GTK+
doesn't export).

>> oh well, setjmp/longjmp seems to be it :(
>
>Be careful, longjmp()'ing with GTK stuff on the stack will not make
>GTK happy.

given that the point is to return to the point where GTK/glib is not
running anymore, it doesn't really matter :) oh, wait. GTK and glib
call on_exit() .... drat.

oh well, time to come up with disgusting hack.

--p