CLIM mail archive
[Prev][Next][Index][Thread]

A Kinder Gentler Event Loop

This helped.  Let me bounce some issues off of you.  I'm trying to
neither give you a solution nor hinder its emergence.

The term "event" in the documentation you quote pretty much does refer
to keyboard and pointer events.  It was designed to cover stuff from
attached devices, and thus should be extensible to joy-sticks, Kanji
tablets, motion detectors, etc.  The theory is/was that these capture
the abstration of "gesture" which is an action taken directly by the
user, and that that action should be delivered to the application.

It might be appropriate to splice "INPUT-EVENT" as a child to "EVENT"
and a parent of all the other events types.  This would distinguish it
from ozone events and timer events, which are indeed events, but not
input events.  Thus, PROCESS-NEXT-EVENT might be renamed to
PROCESS-NEXT-INPUT-EVENT or PROCESS-NEXT-GESTURE.  I would argue that
this is the wrong place for timer events, as timer events are not in
general part of a window system (such as X), but rather a separate
substrate.

I think you want two things: a timer mechanism and a way to
define&deliver events to applications.  You would synthesize these two
things into a mechanism to deliver timer events to applications.

The design trick then, is to define
 -- the way to extend "events" so that you can define ozone
    events and timer events and expect it to work in CLIM,
 -- a standard way CLIM applications can connect to a timer mechanism,
 -- how applications receive/process/queue events so that your timer
    events are handled properly.  I think this is the real trick, which
    I'll try to discuss if I'm on the mark in assessing your goals.



Does all of this sound consistent with the goals you have and the
direction you would like to see things heading, or have I misunderstood
you completely?

0,,
Follow-Ups: References:
Main Index | Thread Index