[squeak-dev] InputSensor, EventSensor miscategorised?

Frank Shearar frank.shearar at gmail.com
Wed Jan 27 10:24:55 UTC 2016


That was my thinking, Chris. But InputSensor is, as far as I can tell,
entirely ST80-specific. It's all about keyboards and pointers _for
ST80_: the equivalent of Morphic's UserInputEvent.

The only packages that reference it are ST80 and System, and System
references it only because of #initializeStartUpList &
#initializeShutDownList. (System has, as far as I can see, had this
"soft" dependency on ST80 since at least 2010.)

Given that, ST80 actually seems like the right place for these classes.

frank

On 27 January 2016 at 02:52, Chris Muller <asqueaker at gmail.com> wrote:
> +1 for Kernel-Input or Kernel-Device.  Sensors are concerned with
> bringing information from the outside world into the software system;
> like the eyes and ears of the computer.
>
> User-interface is concerned with the interactions between the software
> and the user.
>
>
> On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi Frank,
>>
>> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>>
>>> Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker,
>>> Promise, etc. All these work together. They fit nicely in the
>>> category.
>>>
>>> And then there's InputSensor, EventSensor and EventSensorConstants. What.
>>>
>>> Where _should_ these classes belong? Maybe we should have a
>>> Kernel-Device or Kernel-Input category?
>>
>>
>> IMO they don't belong in the Kernel at all.  I would add a UserInterface
>> package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in
>> there.  I'd also consider Headful and Headless packages for precursors of
>> headful and headless apps.
>>
>>> (I'll not mention how Kernel's InputSensor >> #keyboard uses
>>> TextConverter that causes a dependency on Multilingual, which of
>>> course has a dependency on Kernel... oh, wait, I did.)
>>>
>>> frank
>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>


More information about the Squeak-dev mailing list