[GUI] GUIs and events/callbacks.

[Glynn Clements]

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 <glynn.clements@virgin.net>