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

[Wolfgang Thaller]

Nick Name wrote:

> On Wed, 12 Mar 2003 19:05:51 +0100
> Wolfgang Thaller <wolfgang.thaller@gmx.net> 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