Re: how to fully quit out of recursive main loops?
>> 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 :) > >With no apparent negative impact. ;-) ever heard the sound of an audio interface looping through its buffers while the rest of the application shuts down first? this is a resource acquisition/release problem, and it typifies the kinds of things that are best handled by returning to level at which the resources were acquired (ie. before gtk_main_run()). --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to fully quit out of recursive main loops?
Paul Davis <[EMAIL PROTECTED]> writes: > 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 :) With no apparent negative impact. ;-) > 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. Not anymore in 2.0. (Even in 1.2 the atexit doesn't do anything interesting.) Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to fully quit out of recursive main loops?
>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 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to fully quit out of recursive main loops?
Paul Davis <[EMAIL PROTECTED]> writes: > g_main_quit_all (); > > which would apply g_main_quit() to all current main loops. > > it seems like a rather serious design defect, 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. gtk_main_quit() doesn't "mean" exit the app, that's just an interpretation specific apps can apply to it; but if you do that you have to be sure you also have a way to quit all loops, e.g. by recording all loops in a list when you enter them, or have a policy that extra loops will forbid quitting while they are running. I usually do the latter. > though hardly surpising > given the reprehensible way that gtk_exit() works (calling exit(2)). gtk_exit() is totally useless and always has been. Deprecated in 2.0. > i would have thought that a way to say "stop the GUI and release its > resources" was rather important :) 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. > oh well, setjmp/longjmp seems to be it :( Be careful, longjmp()'ing with GTK stuff on the stack will not make GTK happy. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to fully quit out of recursive main loops?
>> why would i want to? imagine the user takes some steps to invoke >> a "quit" function. if there are nested main loops (e.g to run a >> dialog), gtk_main_quit() won't work as a way to return control to >> whatever called gtk_main_run() at the top level. > >People sometimes write "while (gtk_main_level ()) gtk_main_quit()" >but I think it's a big old hack. it doesn't work either. gtk_main_quit() just marks the loop as not running. the level won't change till the current main loop regains control. this code will run forever :) >> ideas? > >In my code the policy I use is that I never nest gtk_main(); for >recursive loops I create my own separate >GMainLoop. e.g. gtk_dialog_run does this. This avoids confusion. Then >I only use gtk_dialog_run sort of stuff if the dialog is modal. but that would then require that the GMainLoop you create be "global", because the quit function activated by the user (e.g. a keyboard entry, a control protocol message, a MIDI event, or some other not-modally-restricted method) would have to know about. i suppose what i'm looking for is: g_main_quit_all (); which would apply g_main_quit() to all current main loops. it seems like a rather serious design defect, though hardly surpising given the reprehensible way that gtk_exit() works (calling exit(2)). i would have thought that a way to say "stop the GUI and release its resources" was rather important :) oh well, setjmp/longjmp seems to be it :( --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to fully quit out of recursive main loops?
Paul Davis <[EMAIL PROTECTED]> writes: > why would i want to? imagine the user takes some steps to invoke > a "quit" function. if there are nested main loops (e.g to run a > dialog), gtk_main_quit() won't work as a way to return control to > whatever called gtk_main_run() at the top level. People sometimes write "while (gtk_main_level ()) gtk_main_quit()" but I think it's a big old hack. > ideas? In my code the policy I use is that I never nest gtk_main(); for recursive loops I create my own separate GMainLoop. e.g. gtk_dialog_run does this. This avoids confusion. Then I only use gtk_dialog_run sort of stuff if the dialog is modal. In GTK 2, delete_event for other windows gets turned off when you have a modal dialog up, in 1.2 there's a bug there that most apps have. (You can close grab-shadowed windows.) Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
