On Mon, Feb 04, 2013 at 01:29:44PM +0000, H. Hirzel wrote:
> Thank you Levente for digging out the reference to an earlier
> discussion of the same problem.
> 
> John M McIntosh
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147307.html
> 
> noted that at that time already EventSensor has been replaced in Pharo and
>  #wait2ms doesn't exist in Pharo.

MVC does not exist in Pharo either. As far as I call tell, wait2ms is called
only when running in MVC. But it might be important for Scratch when running
in Morphic (I don't know).

> 
> And Andreas Raab noted
> " The usage of Sensor in Morphic is completely abusive.
> Sensor isn't a Morphic entity; only the hand should be used to query
> such information."

Right. This specifically refers to usage in Morphic.

> 
> The class comment of InputEventSensor  in Pharo 1.4
> 
> "An InputEventSensor is a replacement for the old Morphic EventSensor framework.
> It updates its state when events are received so that all state based
> users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor
> mouseButtons) will work exactly as before. The usage of these funtions
> is discouraged. "
> 
> Can we take this version? Or are there more things to change?

I don't know the background on why InputEventSensor was written, but it
sounds like it is Morphic specific.

Dave

> 
> --Hannes
> 
> On 2/4/13, Levente Uzonyi <leves at elte.hu> wrote:
> > On Sun, 3 Feb 2013, David T. Lewis wrote:
> >
> >> On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote:
> >>> Dave
> >>>
> >>> I assume you commented out
> >>>    self wait2ms.
> >>> in
> >>>    EventSensor >> primKbdPeek
> >>> and
> >>>    EventSensoer >> primKbdNext
> >>>
> >>
> >> I just commented out the body of the wait2ms method, so effectively
> >> like removing it entirely from the system.
> >>
> >>> this indeed has the effect that the cursor is no positioned correctly
> >>> in MVC when typing fast in an MVC workspace.
> >>>
> >>> What could be the possible side effect of removing the call to
> >>>      self wait2ms
> >>>
> >>> in these two methods?
> >>>
> >>
> >> I don't know. I guess I would want to go back and understand the original
> >> motivation for adding it. A lot a things have changed since 2005, and I
> >> would not want to do a quick fix without understanding it. But for now
> >> I'll leave it commented out in my own image :)
> >
> > The author's explanation is here:
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147269.html
> > It's also worth reading the responses.
> >
> > We should consider checking the EventSensor replacement in Pharo, because
> > it probably became mature enough by now.
> >
> >
> > Levente
> >
> >>
> >>> --Hannes
> >>>
> >>>
> >>> On 2/3/13, David T. Lewis <lewis at mail.msen.com> wrote:
> >>>> On Sun, Feb 03, 2013 at 10:33:14AM +0100, St??phane Rollandin wrote:
> >>>>> Also I found this on the web:
> >>>>> http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html
> >>>>>
> >>>>> from where it seems that the reason for the wait is related to system
> >>>>> window panes resizing logic...
> >>>>
> >>>> Stef,
> >>>>
> >>>> Wow, you just found the cause of our badly broken keyboard entry in MVC
> >>>> :)
> >>>>
> >>>> Since about Squeak 3.9, keyboard entry (especially on Linux) has had an
> >>>> odd latency delay that makes it all but unusable. I just tried
> >>>> commenting
> >>>> out the wait2ms, and suddenly keyboard entry is working again. I see no
> >>>> immediately obvious ill effects (cpu use does not go too high, and
> >>>> things
> >>>> generally still work fine).
> >>>>
> >>>> It seems that the delay was added back in about 2005, and very likely
> >>>> the changes to input events in the Squeak 3.9 time frame caused it to
> >>>> become a problem. I'm not sure the right way to fix this, but at least
> >>>> now we know the source of the problem.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Dave
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >