[GUI] GUIs and events/callbacks.

[Nick Name]

On Fri, 7 Mar 2003 11:07:39 +0000
Glynn Clements <glynn.clements@virgin.net> wrote:

> 
> 
>  And what about inter-related callbacks? E.g. for composite widgets
>  (e.g. a scrolled window), both the composite widget and all of its
>  individual components may provide callbacks. 

Well, what I have in mind is that callbacks and events really are dual:
it's the same thing to listen to an event or to install a callback. So a
composite widget will have, as event, a (possibly tagged) merge of the
composing widgets events. 

> Sometimes, a single
> event may invoke multiple callbacks.
> 

If one wants to handle multiple events simultaneously, and to handle
them with streams and not with callbacks, he has two choiches: merge the
handler code, or (really easier and better) use multi-threading, as I do
in my tests these days.

There are examples wich just look nice with this approach, and look
weird with callbacks, I'll post here but I don't know if I have time
this weekend.

>  Basically, it seems that this is moving far enough away from the
>  toolkit's native behaviour that it may be making life harder for the
>  application programmer.
> 

Well, I don't want to renounce to streams because having to handle
everything with an IO action moves away from the functional programming!

There are cases in wich a callback is just better, though. And I doubt
that anyone is willing to abandon callbacks :)

>  > However, I think that when you are waiting for an event, you are
>  > implicitly discarding others.
> 
>  Do you mean "discarding" (i.e. nothing will ever happen in response
>  to those events) or "ignoring" (i.e. the code performing the listen
>  doesn't respond to those events, but something else might)?
> 

If there is code listening to an event, be it a callback or a thread
mapping onto a stream, it will receive the event. This is achieved with
multithreading in my tests. But the thread wich performs a "waitevent"
operation is waiting for just that event.

>  > If you want to listen to
>  > two streams, either you merge them, or you use a separate thread
>  > for each stream.
> 
>  That doesn't sound like the way most toolkits work.
>
>  Either I've completely misunderstood what you're proposing, or it's
>  so far removed from typical GUI idioms that it's bound to be a
>  mistake. I hope that it's the former.
>

Are we all talking of the same thing? I hope that I have understood well
what George Russel is calling "Event": a datatype holding a value
changing over time, wich allows waiting for a value (and possibly
listening to the stream of all values); M. Chackravarty's Ports library
is an example of this abstraction;

It's just like using getContents instead of installing a callback for
the keyboard: there are many cases in wich it's just better!

Of course using streams for events is far away from traditional GUI
paradigm, and of course monads exist because streams are uncomfortable
in many situations, but streams are a typical abstraction in a lazy
language and we cannot decide to drop them out so easily, if we can keep
them.

OTOH, we also need callbacks, as I previously stated.

>  If you have a specific architecture in mind, one which could be
>  implemented in Haskell on top of backends which only provide
>  callbacks, then none of this is an issue. OTOH, if you're relying
>  upon having the backend provide an event stream, then that's a
>  problem.

I have already posted working code in the thread "some random thought of
my own", but I still have not handled the case of uninstalling callbacks
(this issue is mentioned in the file "Var.hs"). However results are
comfortable: my code for John Meacham example is not suffering of the
"click too fast" problem, for obvious reasons; and it's highly readable.
I would like you to read my code, if you have time.

I am going to keep on working to transform the Var library in a non-toy
thing: actually I started experimenting on Var's in summer, but had no
time. This discussion is motivating me.

An important note is that my code doesn't mean MY IDEAS, or someone will
feel offended. :-)

Vincenzo