[ENH] OS-level events

Peter William Lount peter at smalltalk.org
Thu Jul 1 02:46:20 UTC 1999


Hi Peter,

One difference with keyboard and mouse events it is that in the general
case the "ACTIVE" window consumes them while the other windows ignore them
unless the event is a one (like a button down event in an inactive window)
that causes the window to become active. Drag and drop is an exception to
this general rule where as you drag (with the mouse pressed down) over
windows and their views "event" messages are generated for whatever window
(active or inactive) is below the mouse. Also, the "active" window gets to
"remove" events from the keyboard and mouse queue as it needs to.

Another class of events that is useful to an application is the "Timer"
event.

Remote events from other system may not be relevant to a particular window
unless they are "remote mouse and keyboard events".

So we have events that appear on the event queue in different ways and we
have events that need to be removed from the queue in different ways. Do we
have different queues? Do we have one queue with different ways of
distributing and consuming events? It's a design issue and each design
choice will open up it's own issues.

In NeXTStep/OpenStep/MacOSX there is an NSApplication object that is the
"main" loop of an application program. This NSApplication instance reads
the events, distributes the events to the current "event responder" in the
current active window, and if no one consumes the event it it is then
processed by the NSApplication instance itself to see if its a menu
keyboard shortcut. This allows the NSApplication instance to have one
steady stream of events, including remote events from the Portable
Distributed Objects link an application can have, and respond to them
apporpiately. First by asking if any other objects "respond" to the event,
given the current context the application is in and then by handeling the
event itself.

So the design of a single event queue has been successful in at least one
production system (that I know of). 

One of my questions is "what will happen to the Controller loop" with an
event based Smalltalk"? I guess that it goes away and gets replaced by
something like the NSApplication loop. I'll have to explore some event
based Smalltalks to find out... What are you guys planning to do with the
controller loops?

All the best,

Peter William Lount
peter at smalltalk.org
http://www.smalltalk.org

----------
From: Peter Smet <peter.smet at flinders.edu.au>
To: squeak at cs.uiuc.edu
Subject: Re: [ENH] OS-level events
Date: June 30, 1999 4:02 PM

My understanding of events is much more basic than the others discussing
this issue, but I have a naive question.

Why are low level OS events like mouse clicks and keyboard strokes treated
differently from a general events mechanism? By this I mean a mechanism for
passing messages to 'subscribers' whenever an object emits an event
(publish-subscribe)? It seems to me that any event still has an Object from
which it originates, and one or more objects that will be told the event
has
occurred. Why can't low and high level events share the same abstractions,
and even be placed on the same event queue? I also think exception-handling
has much in common with event handling (on: exception do: aBlock). The
exception looks to me very much like an 'event' that the block is told
about. Is it possible to fuse these three mechanisms into a common
abstraction and reuse a lot of the code, or is this just wishful thinking
on
my part?

Peter

From: Reinier van Loon <R.L.J.M.W.van.Loon at inter.nl.net>
To: squeak at cs.uiuc.edu <squeak at cs.uiuc.edu>
Date: Thursday, July 01, 1999 6:06 AM
Subject: Re: [ENH] OS-level events


>I keep getting the impression that the event systems designed so far are
>only concerned with keyboard or mouse events. These events are then put in
>an event queue with some information regarding the event.
>
>Why not define an event as <time, object> and event queue as a collection
>sorted by time?
>The global event (interrupt) handler detects an event on the queue (tim's
>work) and gets the rest of the event of the object mentioned in the event.
>
>In this way, each object (keyboard, mouse, network, etc.) can have it's
own
>buffer.
>And composite events are detected easily by comparing the time stamps.
>
>You could even start new processes to deal with events or have different
>event handlers wait on the queues of the objects. No 'centralized' event
>queue anymore.
>
>Just an idea.
>
>Reinier.
>
>





More information about the Squeak-dev mailing list