[GUI] GUIs and events/callbacks.

Nick Name nick.name@inwind.it
Fri, 7 Mar 2003 16:48:29 +0100


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

> 
>  I don't think that I understood any of that, so I'll just elaborate
>  upon my main concern.
> 
>  Under X, you have to tell the X server which events it should
>  actually send to the client (as opposed to Windows, which reports
>  every event, and the code just ignores the ones it isn't interested
>  in).
> 
>  Generally, you don't ask the X server to send you any events you
>  don't actually need, as the bandwidth between the client and the X
>  server may be limited. In particular, you don't ask it to send
>  MotionNotify(mouse movement) events unless you actually want them.

Yes, this is a problem in any toolkit. What I said is that you can ask
the GUI to send events only when there is someone listening to the
event. I am pretty sure I can do this easily, but let me some day to
produce an example. The idea is:

-- You get a stream when you need it, with an IO action
data Stream a = Stream (IO [a]) 

-- A function to create a stream
newStream :: IO () -> IO () -> Stream a

When you create a stream you pass two IO actions: one to "activate" the
stream, on the first invocation of its IO action, and the other to
"deactivate" (say, unregister the callbacks), when the last list
produced with its IO action gets garbage collected.

Don't say this is too complicate now, it might be simpler than it seems,
and streams are important if we aren't going to turn haskell code into
purely imperative programming. (this will follow in the other opened
thread, of course :)).

Another way is this:

data Stream a = Stream (IO [a],IO ())

where the second component is an action that the user of the library
explicitly calls when he does not need other inputs from the stream
(which is then closed).

This avoids the callback remaining installed until garbage collection,
but I dislike this approach, is too few automatized. I have to think
more, because I believe there is a third alternative to force an early,
predictable uninstalling of the callback as soon as there are no more
listeners.

Vincenzo