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

A Kinder Gentler Event Loop

ciao,

David Linden opened with:

	There is no try.  There is "do", and "not do".

I love this quotation, it used to adorn my terminal.  Thank-you for reminding
me of its existence.

David continued:

	In regards to the functionality you are trying to get: it took me a
	while to unite "events" with "input events."  At first I thought you just
	wanted timers that ran little pieces of code at periodic intervals or when the
	clock stuck 2.  Then I noticed you wanted "events" to be synthesized for a
	frame?  Or do you want events to be synthesized for a port?  I'm not sure what
	you are trying to do or what your higher level goal is.

Let's start with, "I'm not sure what you are trying to do or what your higher
level goal is."  When I first encountered CLIM I actually took a few moments to
look at the introduction, I have learned from experience that on occasion
valuable insight can be garnered from it, and I read, "CLIM attempts to
abstract out shared concepts in the host window systems."  This is nice, but is
it useful?  Yes, most assuredly it is.  Ah, but is it useful if there is no
easy methodology for incorporating the rest of an application's event handling
into the CLIM framework?  I would argue the value of event handling in CLIM
becomes tenuous.  Application developers currently have hefty overheads to
contend with in the development of their application (Common Lisp manuals that
are 900+ pages, CLIM documentation that should be 900+ pages ;-) CLIM is
involved with an ambitious and meritorious effort to aid the application
developer.  Is it wise to force the developer to maintain two or more event
handling mechanisms?

In looking at the documentation regarding basic input, we find that there
exists a 'standard' event hierarchy:

Nota Bene :
 "That this list is not intended to be exhaustive for all time, and
  may be (in fact, will likely be) expanded or otherwise modified in the future."

  event			(Note, '...' refers to additional specific event types)
    device-event
      key-event
        ...
      button-event
        ...
      motion-event
        ...

I do not have a solid proposal for the functionality I am seeking.  But in
order to continue the discussion I shall put forth an illustration:

  event			(Note, '...' refers to additional event types)
    device-event
      key-event
        ...
      button-event
        ...
      motion-event
        ...
    OZONE-EVENT
      TIMER-EVENT
        PERIODIC-EVENT
        TIMED-EVENT
          IDLE-EVENT
      ...

The ozone represents events which the application must deal with that are not
related to a user accessible device.  Nonetheless, these events have their role
in the user's world.

Timer events, I will acknowledge, more often than not are a means to an end.  A
powerful means, however, to a common end.  Many a nasty code segment I have
seen that was an attempt to achieve what a simple timer would supply.  I know
that we are all aware here of the nature of timers and their relation to
application interface, so I will not belabor this issue.

Idle events create an abstraction for timeouts and as such are not needed by
all applications.  Notice that I put forth the notion that timeout is, in fact,
a specialization of a timed-event.  A timed-event is a single shot timer-event
(yes, ala Unix).

My high level goal in all of this is to create an event layer that can be used
as the application's mechanisms for handling events.  This may require some
extensions on their part for highly specialized events, but possible nonetheless.
As it stands now, I see little possibility for the application developer to use
the CLIM event metaphor as the unifying event handling mechanism I believe is
needed.

	mas

Please don't dominate the rap, Jack
If you've got nothing new to say
If you please, don't back up the track
This train's got to run today



0,,
Follow-Ups: References:
Main Index | Thread Index