>     Sorry, I still can't get behind a universal UI event abstraction.
>
> Not even as a plist?  Different event types can have different keys ad
> infinitum, with the exception of the event-type key itself (which should
> come first in the plist).

That sounds fine. I didn't think that would qualify as an abstraction.
Since standard Scheme doesn't have extensible record types, I was
worrying you were making a standardized record type which has too few
fields for advanced purposes :)

> Just to look at the single example of multiple pointing devices, they
> would still generate mouse-move and mouse-click events, but with an
> additional key identifying the particular mouse (and likewise for
> fingers on a multitouch screen). Similarly, a 3-D mouse (I"ve actually
> used one, clamped to the edge of a desk) would fire off the same mouse
> events with a different key representing it's z-position.

Makes sense.

>     If they use the same field names, that's nice.
>
> Such niceness doesn't happen unless someone takes pains to make it happen.

OK, let's do it.

>     I don't understand event-poll. How and why would one procedure return
>     events from many sources?
>
> Not just any old sources, but events that reflect user actions.  The
> mouse and the keyboard are really very similar generators of user
> events, and the two of them are equally relevant to a terminal or a
> canvas.

I'm not sure how similar they are. The resolution has to be much finer
for the mouse in order for things like drag-and-drop and paint programs
to work nicely. That has especially big implications for
over-the-network things like the X protocol. VR stuff can actually make
people nauseous if the resolution is not fine enough.

It sounds like we're ending up with `ui-event-ref` like we have for
foreign statuses :) In the end, everything becomes a dictionary.

> (The `conflict` event is a special case, but that's needed
> because turtles can move autonomously with respect to the Scheme
> program, so it feels to the programmer like something coming from
> outside at unpredictable moments, just like keystrokes or mouse clicks
> or movements.)

Is conflict about collision?

> I would widen that in the Lisp context to "things that aren't expected
> to happen", like resource exhaustion.  You can signal that and ask an
> outer level of the program to supply more of the resource if it can and
> then exit the handler or (if there are restarts) use a `retry` restart.

Sure, that's what I meant :)