*) non-modal windows: If a callback wants to open a non-modal window, it should just open the window, attach some callbacks to the window and return to the main event loop. No special issues here.
*) application-modal dialogs: For application-modal windows, at least Win32 and Apple's APIs (don't know about GTK and others) provide a function that runs a nested event loop. For expose events and other events that still have to be handled when a modal dialog is active, this nested event loop invokes the appropriate callbacks. For information: yes, same thing in Gtk. You just call mainLoop again (or runDialog) which lets the global event loop run. The underlying application window would still emit redraw/expose events but no buttons could be pressed since it cannot get the input focus as long as the modal
On Wed, Mar 12, 2003 at 11:46:57PM +0100, Wolfgang Thaller wrote: dialog is open. I guess this is the same in all three backends. [..]
1) We should adopt a callback scheme that does not require concurrency 2) CGA implementations should automatically do all necessary synchronization so that the CGA fully supports concurrency even if the backend library does not. (2b) We should be careful to ensure that CGA functions can be invoked from a "background" thread while the "main" thread is waiting for events (means additional work, but it is probably necessary if we want to fully use concurrency). Glynn oposed to this, he said it could be very difficult or even impossible. I thought this would come for free with the FFI if we wrap all GUI calls with
foreign ccall thread "GUI" blah... which means all calls are done from a single OS thread called "GUI". I suspect this didn't wind up in the FFI, or did it? Axel.