On Fri, 7 Mar 2003 01:12:22 +0000
Glynn Clements
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