InputSensor, EventSensor miscategorised?

> Hi Frank,
>
> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
> 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
>
>
>

> +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 <[hidden email]> wrote:
>> Hi Frank,
>>
>> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
>> 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
>>
>>
>>
>

> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >> Hi Frank,
> >>
> >> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
> >> 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
> >>
> >>
> >>
> >

> On Wed, Jan 27, 2016 at 10:24:55AM +0000, Frank Shearar wrote:
>> 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.
>
> That sounds reasonable, but one sanity check: ST80 is a reloadable package
> (or at least it was, and it definitely /should/ be). I think that will
> still be the case if we move InputSensor to ST80, but I'd want to check
> and make sure we don't break the unloadable/reloadable aspect.
>
> This is probably a non-issue, but I can't check it right now so I'm just
> mentioning it as a reminder.
>
> Dave
>
>
>>
>> frank
>>
>> On 27 January 2016 at 02:52, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:
>> >> Hi Frank,
>> >>
>> >> On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar <[hidden email]>
>> >> 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
>> >>
>> >>
>> >>
>> >
>

>
>> On 29-01-2016, at 8:45 AM, Chris Muller <[hidden email]> wrote:
>>
>> How could we possibly unload InputSensor?  Isn't that what generates
>> the events necessary to interact with the system?  IOW, you wouldn't
>> be able to reload ST80 without InputSensor, right?
>
> It’s been some time since I dug into it and I’m all wrapped up in transforms right now so I won’t be diverting back to it soon, but I’m reasonably certain that InputSensor is actually unused except as a superclass for EventSensor. I don't recall any places where an actual InputSensor ever gets to exist, let alone get used. In MVC projects the Sensor global is an EventSensor, for example. So ‘anyButtonPressed' as I recall uses something like primMouseButtons, which actually goes via the EventSensor version and fetches events to update the variable rather than the ancient primitive.
>
> Some clean-up work could completely get rid of InputSensor
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Trojan:  Storage device for replicating codes...
>
>
>

> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>
>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>
>>> You can't unload a superclass without unloading its subclasses.  So,
>>> let me rephrase the question:  How could EventSensor be unloaded and
>>> then reloaded?
>>
>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>
> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
> Nothing points to InputSensor. Nothing points to
> EventPointerConstants.
>
> So why not in a postload of ST80, evaluate
>
>    Environment current bind: #Sensor to: EventSensor
>
> ?

> Hi Frank,
>
>> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>>
>>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>>
>>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>>
>>>> You can't unload a superclass without unloading its subclasses.  So,
>>>> let me rephrase the question:  How could EventSensor be unloaded and
>>>> then reloaded?
>>>
>>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>>
>> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
>> Nothing points to InputSensor. Nothing points to
>> EventPointerConstants.
>>
>> So why not in a postload of ST80, evaluate
>>
>>    Environment current bind: #Sensor to: EventSensor
>>
>> ?
>
>  Sounds reasonable, but why not use (or add) EventSensor class>>initialize?  The post load strikes me as too fancy.

> On Jan 29, 2016, at 1:28 PM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2016 at 20:41, Eliot Miranda <[hidden email]> wrote:
>> Hi Frank,
>>
>>>> On Jan 29, 2016, at 12:01 PM, Frank Shearar <[hidden email]> wrote:
>>>>
>>>>> On 29 January 2016 at 18:07, tim Rowledge <[hidden email]> wrote:
>>>>>
>>>>> On 29-01-2016, at 9:43 AM, Chris Muller <[hidden email]> wrote:
>>>>>
>>>>> You can't unload a superclass without unloading its subclasses.  So,
>>>>> let me rephrase the question:  How could EventSensor be unloaded and
>>>>> then reloaded?
>>>>
>>>> Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
>>>
>>> In a Trunk image, only Smalltalk at: #Sensor points to EventSensor.
>>> Nothing points to InputSensor. Nothing points to
>>> EventPointerConstants.
>>>
>>> So why not in a postload of ST80, evaluate
>>>
>>>   Environment current bind: #Sensor to: EventSensor
>>>
>>> ?
>>

>> Sounds reasonable, but why not use (or add) EventSensor class>>initialize?  The post load strikes me as too fancy.
>
> Because I'd forgotten I could do that :) There is an EventSensor
> class>>install which sounds like it would do the right thing, but it
> doesn't. It seems like the right thing to do then is to add an
> initialize like this:
>
> initialize
>    Environment current bind: #Sensor to: EventSensor.
>
> Sound good?
>
> frank
>
>>> frank
>>>
>>>> tim
>>>> --
>>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>>> Strange OpCodes: DCBP: Detonate Chair on Bad Password
>

> On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> wrote:
> >
> > initialize
> >    Environment current bind: #Sensor to: EventSensor.
> >
> > Sound good?
>
> Nope.
>
> You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
>
> The easiest thing would be to simply move InputSensor into the same package as EventSensor.
>
> Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
>
> Packaging-wise the result would be the same: no InputSensor in the St80 package.
>
> - Bert -
>

> On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> wrote:
>>
>> initialize
>>    Environment current bind: #Sensor to: EventSensor.
>>
>> Sound good?
>
> Nope.
>
> You don’t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
>
> The easiest thing would be to simply move InputSensor into the same package as EventSensor.

> On 29 January 2016 at 22:08, Bert Freudenberg <[hidden email]> wrote:
> > On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> wrote:
> >>
> >> initialize
> >>    Environment current bind: #Sensor to: EventSensor.
> >>
> >> Sound good?
> >
> > Nope.
> >
> > You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
> >
> > The easiest thing would be to simply move InputSensor into the same package as EventSensor.
>
> They are both in Kernel. Which is where I don't want them :)
>
> > Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
> >
> > Packaging-wise the result would be the same: no InputSensor in the St80 package.
>
> Let's wind back a bit. I'm not really interested in InputSensor &
> EventSensor's relationship. I care that Kernel has these classes, when
> nothing in Kernel even uses them. They don't belong there.
>
> But it turns out that while ST80 still refers to InputSensor -
> Controller class >> #initialize calls InputSensor default -
> InputSensor default actually returns an EventSensor.
>
> Thing is, Sensor is referenced by a whole ton of packages - Tools,
> Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is
> wrong. Therefore, I think we need to put InputSensor, EventSensor and
> EventSensorConstants into _System_.
>
> And we don't need any package initialization or anything else like that.
>
> As an aside, this investigation has revealed that Dependency Browser
> needs an upgrade: it's not enough to know which classes in a package
> reference which classes in other packages. Dependency Browser also
> needs to track dependencies induced via globals - "what globals does
> this package reference? what are the classes of those globals? in
> which packages are those classes defined? therefore this package
> depends on those packages.")
>
> frank
>
> > - Bert -

> Please hold off on moving anything for a few days. I'm working (in the inbox)
> on making InputSensor go away.
>
> Dave
>
>
> On Sat, Jan 30, 2016 at 06:49:17PM +0000, Frank Shearar wrote:
>> On 29 January 2016 at 22:08, Bert Freudenberg <[hidden email]> wrote:
>> > On 29.01.2016, at 22:28, Frank Shearar <[hidden email]> wrote:
>> >>
>> >> initialize
>> >>    Environment current bind: #Sensor to: EventSensor.
>> >>
>> >> Sound good?
>> >
>> > Nope.
>> >
>> > You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
>> >
>> > The easiest thing would be to simply move InputSensor into the same package as EventSensor.
>>
>> They are both in Kernel. Which is where I don't want them :)
>>
>> > Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
>> >
>> > Packaging-wise the result would be the same: no InputSensor in the St80 package.
>>
>> Let's wind back a bit. I'm not really interested in InputSensor &
>> EventSensor's relationship. I care that Kernel has these classes, when
>> nothing in Kernel even uses them. They don't belong there.
>>
>> But it turns out that while ST80 still refers to InputSensor -
>> Controller class >> #initialize calls InputSensor default -
>> InputSensor default actually returns an EventSensor.
>>
>> Thing is, Sensor is referenced by a whole ton of packages - Tools,
>> Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is
>> wrong. Therefore, I think we need to put InputSensor, EventSensor and
>> EventSensorConstants into _System_.
>>
>> And we don't need any package initialization or anything else like that.
>>
>> As an aside, this investigation has revealed that Dependency Browser
>> needs an upgrade: it's not enough to know which classes in a package
>> reference which classes in other packages. Dependency Browser also
>> needs to track dependencies induced via globals - "what globals does
>> this package reference? what are the classes of those globals? in
>> which packages are those classes defined? therefore this package
>> depends on those packages.")
>>
>> frank
>>
>> > - Bert -
>