[GUI] GUIs and events/callbacks.

[Nick Name]

On Fri, 7 Mar 2003 01:12:22 +0000
Glynn Clements <glynn.clements@virgin.net> wrote:

> 
>  Does this mechanism allow the toolkit to determine whether an event
>  is being listened for? Or would it force the toolkit to always
>  generate all events just in case it's being listened for? The latter
>  is unacceptable on X.

We can have "automatically activating" streams; it would be useful to
have the "mouse positions" streams, but it's unacceptable to always get
mouse position, for example. So the idea is simple: just provide a "Var"
(event and ability to write to it) constructor wich looks like

mkAutomaticVar :: IO () -> IO () -> a -> Var a

where the first two arguments are the actions to execute when the first
listener is added and when the last listener is garbage collected. The
matter is how to catch the garbage collection, maybe with weak pointers.
I guess you know more than me, so tell me what you think.

Again, since I am not biased, I would like to provide both events and
callbacks. With multithreading, callbacks are easily derived from
events.

> 
>  > To "listen" for events, two functions would be provided:
>  > 
>  >     sync :: Event a -> IO a
>  > 
>  > which blocks until the event happens (or returns immediately if a
>  > queued occurence of this event has already happened), and
> 
>  This implies modality, which is usually a bad thing. Also, it sounds
>  like a recipe for non-portability; what happens in response to all
>  the other events which turn up while you're waiting for this specific
>  event?
> 

What is modality? However, I think that when you are waiting for an
event, you are implicitly discarding others. If you want to listen to
two streams, either you merge them, or you use a separate thread for
each stream.

>  I suspect that multiple callbacks could be quite common; if so, it
>  would be better for the GUI system to implement this directly than
>  for each application to roll its own "callback multiplexer".

I agree here.

Vincenzo