[GUI] Re: Events and finalizers

Axel Simon A.Simon@ukc.ac.uk
Wed, 12 Mar 2003 08:41:19 +0000


On Tue, Mar 11, 2003 at 04:19:08PM +0100, Nick Name wrote:
> Yes, and this is way I say "let's work together". You have to point out
> your issues, everybody else their. We 'll see what stream semantics we
> are interested in and what are too complex or too rarely used, and
> decide what's "inside" the library and what's "outside", or else the
> work could have been done here in the GUI ml.
> 
> Let's put a deadline, say two months to make the specification of an
> extensible kernel and to write a correct implementation - if we don't
> have anything till that deadline, we'll surrender :) Also because I have
> to ask for my thesis, and after that will not have so much time.
 Having looked at the Haskell files you sent around some time ago, me
thinks that such a unified event/syncronization/stream library is too high
level for the CGA. In case a) it can be implemented on top of the callback
approach then we/you should be able to define a separate library (ok, I
said that before) which can be part of a Common GUI Library (i.e.
libraries which work with the CGA). In case b), that it has to be
interweaved with the API itself, then it will make it hard for high level
libraries to use the CGA since they have to match the concurrency model of
your approach.

I really don't mind having these abstractions, in fact I would try to use 
them in my applications. But there are so many other approaches that never 
really caught on which is why we don't want a high-level solution. I know 
you don't force the user to use your abstractions which contrasts with 
high-level approaches like Fudgets, Fran, etc, but that should mean that 
the library can be an addition to the core.

About the time scale: How events are modelled is part of the core library 
(like creation of widgets and layout). Before we do anything else, we have 
to define this core. Waiting for two months is not too appealing.

Sorry to be so negative,
Axel.