[GUI] GUIs and events (was: Re: Concurrency)
Thu, 13 Mar 2003 11:55:21 +0000
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?