Re: GUIs and events (was: Re: Concurrency)

On Wed, Mar 12, 2003 at 11:46:57PM +0100, Wolfgang Thaller wrote:
> *) 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
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.