Re: [GUI] GUIs and events (was: Re: Concurrency)

Nick Name wrote:

On Wed, 12 Mar 2003 19:05:51 +0100 Wolfgang Thaller wrote:

...

1a) Event loops may be nested, i.e. a callback, or (if proposal 2 is also accepted), any other IO action, may call a CGA function that runs another event loop, e.g. for handling an application-modal dialog (the main event loop won't handle events during that time).

I am sorry to make you repeat yourself, but I wish to understand it well. Event loops may be nested

... in order to allow application-modal dialogs to be created as easily as with Win32, Carbon, GTK, etc.

, but: there will be a way to avoid that. Is this what you are saying?

I haven't said that. But it's probably a good idea. However, I think this is a (partly) independent issue, so those details should be discussed separately (as point 3, for example). I was only saying that we should do without concurrency by default (unless somebody wants to use concurrency). It's obvious that all kinds of applications are possible that way (GTK, Win32, Carbon, Cocoa, Swing and many more all work without concurrency). The discussion about how to do it exactly, how to handle modal dialogs and other things like that should probably be the next discussion topic.

There needs to be a way to make both a callback and its parent window handle events simultaneously, even in non-preemptive environments, without forkIO.

Agreed (at least if I understood you correctly). Here's a first guess on how things could be done. This is not a real proposal yet, it's just a first guess, heavily influenced by Apple's APIs: *) 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. *) window-modal dialogs: We should also support window-modal dialogs for those platforms that support it --- I only know that they are supported on Mac OS X, I'm not sure if users of other platforms would even want them. If a backend doesn't support window-modal dialogs, it can treat them as application-modal instead. The above things are just first ideas. The main point is, who agrees/disagrees that (I'm just rephrasing my original two points again): 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). Cheers, Wolfgang