We wrote another blog entry on the design of Microverse. post 
, discord
It has some personal take on the history of application frameworks and where Microverse is going from here.
> One of the major components of a user interface framework is how the user event is “routed” and how the right event handler is invoked. Event routing is so that when a user uses their mouse or hits a key on their keyboard, the event routing mechanism selects the right object and invokes the right event based on the location of the event and some kind of focus policy. On the surface, it may sound trivial, but in practice it has a lot of intricacies, as it must be designed together with all other parts of the framework. In this blog entry, I will discuss the ideas behind the Microverse Framework.
⇒ MVC
Ward — discord
Thanks again for the history. I have a small quibble with the way you describe Controller Event Handling in Smalltalk (presumably Smalltalk-80).
> When the user pushes the mouse button, the system chooses the right controller based on the location of the mouse, and the controller invokes a method on the model to cause some state changes, and the view updates […] its screen area based on the state change.
>
Directing mouse button activity was handled by the network of controllers being perfect gentlemen and working independently of any central system resource other than the mouse itself.
A controller would be asked if it wanted control responsibility. It would sample the mouse coordinates directly and compare them to the space occupied by the corresponding view. Once a controller accepted responsibility it would poll any sub controllers it might contain and delegate further if they wanted control by similar logic.
⇒ Polling and Coroutines – Smalltalk’s controllers poll for both input and control.
This approach illustrated perfectly that the computer was an extension of the person and had nothing more important to do than be ready to interpret Mouse activity.
Oddly, developers in our lab were eager make something graphical with the, for us, brand new Smalltalk. A common mistake was to program a Clock which was unable to tick because this didn't fit the control paradigm. **A clock, after all, tells people what to do, not the other way around.**
This approach melted away as smalltalk was made to work in other operating systems. Remember, originally there wasn't suppose to be any operating system other than smalltalk. See page ⇒ Design Principles Behind Smalltalk.
yoshiki — discord
Thank you! I agree that the description does gross over some details. By the "system" I was thinking that […] the network of controllers working together is a part of it, but as you mentioned it is not as simple as the simply finding the hit.
~
# Controller Event Handling in Smalltalk
VAN DER MEULEN, Pieter S., 1987. INSIST: Interactive Simulation in Smalltalk. ACM SIGPLAN Notices. 1 December 1987. Vol. 22, no. 12, p. 366–376. DOI 10.1145/38807.38840. > A functional simulator/editor for VLSI design has been implemented in the Smalltalk-80 system. Users can explore their designs in an highly interactive and graphical manner with “close-to-reality” tools. The traditional sequence of editing, compiling and simulating the circuit is avoided. During editing, functional Modules can immediately respond to new connections. The simulator, called INSIST, strongly supports hierarchical simulation and design up to gate level. Hardware descriptions of the design can be generated for other CAD systems. From these descriptions layout has been generated. A RISC chip was entered and simulated at three hierarchical levels containing more than 50 Modules.
[Cunningham 85) H.Cunningham, The construction of Smalltalk-Applications, Tektronix - Advanced Smalltalk class-notes, November 1985.
DOT FROM lambda-browsing