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
On Tue, Mar 11, 2003 at 04:19:08PM +0100, Nick Name wrote: 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.