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@smalltalk.org http://www.smalltalk.org
---------- From: Peter Smet peter.smet@flinders.edu.au To: squeak@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@inter.nl.net To: squeak@cs.uiuc.edu squeak@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.
squeak-dev@lists.squeakfoundation.org