George Russell wrote:
I think I've pointed out that the main difference between GIO and HTk is that HTk uses composable events, while GIO, like most other Haskell GUI's (including GTk+hs) use callbacks.
Now of course I'm biased, and I prefer events to callbacks,
I'm biased too, but in the other direction. Apart from personal preference, the callback model is more common in mainstream GUI environments.
but I appreciate the arguments that have been made that including composable events in a GUI would simply involve adding too much heavy machinery which doesn't have anything to do with graphics.
But I think I have a solution to this, which I would like to propose. This is that a GUI standard specify events, but *doesn't* specify that they be composable. Then they would be trivial to implement, and still (in my opinion) be better than callbacks. Also systems like HTk could of course add an extra module which did provide the composition operators.
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.
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?
There are questions to be asked about what happens when you have multiple consumers of the same event. I think it should be guaranteed that when an event happens, only one consumer gets to hear about it, but which does not perhaps need to be specified. (I don't think this is very likely anyway.)
Personally, I'd prefer to allow multiple callbacks. Xt supports this
directly (each action has a list of callbacks); for toolkits which
only support a single callback, the abstraction layer would, when the
callback list wasn't empty, install a callback which iterates through
the callback list.
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".
--
Glynn Clements