InputSensor next step cleanup

>
>> do you have one example so that I can evaluate?
>
> there are differents use cases of referencing Sensor (Except examples which could simple be removed from the image).
>
> - asking for the current cursor position (which is the majority of the references)
> e.g.
> 'Scanning ', aFile localName, '...'
> displayProgressAt: Sensor cursorPoint
> from: startPosition to: stopPosition
> during: [:bar |
>
> This could be replaced by Display center, the current active Window position or things like that.
>
> - asking for the state of modifier keys
>
> shift := Sensor leftShiftDown.
>
> This needs some refactoring to hand down the current event into these methods. I already refactored a few of these methods when cleaning up the unicode handling but not all.
>
>
> - the worst offender is actually polling
> e.g.
> newRectFrom: newRectBlock
>
> ...
> [ Sensor nextEvent isNil ] whileFalse.
> buttonNow := Sensor anyButtonPressed.
> newRect := newRectBlock value: rect.
> ...
>
> Not always easy to code around this, as you need stateful event handling to replace the polling. On the other hand it looks like the method could simply be removed as there don't seem to be any important callers left.
>
> Michael

>>
>>> do you have one example so that I can evaluate?
>>
>> there are differents use cases of referencing Sensor (Except examples which could simple be removed from the image).
>>
>> - asking for the current cursor position (which is the majority of the references)
>> e.g.
>> 'Scanning ', aFile localName, '...'
>>       displayProgressAt: Sensor cursorPoint
>>       from: startPosition to: stopPosition
>>       during: [:bar |
>>
>> This could be replaced by Display center, the current active Window position or things like that.
>>
>> - asking for the state of modifier keys
>>
>> shift := Sensor leftShiftDown.
>>
>> This needs some refactoring to hand down the current event into these methods. I already refactored a few of these methods when cleaning up the unicode handling but not all.
>>
>>
>> - the worst offender is actually polling
>> e.g.
>> newRectFrom: newRectBlock
>>
>> ...
>> [ Sensor nextEvent isNil ] whileFalse.
>> buttonNow := Sensor anyButtonPressed.
>> newRect := newRectBlock value: rect.
>> ...
>>

>> Not always easy to code around this, as you need stateful event handling to replace the polling. On the other hand it looks like the method could simply be removed as there don't seem to be any important callers left.
>>
>> Michael
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On 1/13/2010 11:13 AM, Igor Stasenko wrote:
>
>> Next step is removing a direct reference to Sensor global, and replace
>> it with something like:
>>
>> self eventSensor
>
> No, that is fixing a sympton, not the problem.
> (John will love this ;-) )
>
> You would still be polling the sensor. There should be no references to
> Sensor -directly or indirectly- at all. The system should be completely
> event driven and not be allowed to ask for anything. I know it is just
> so comfortable to do this, but a very bad idea.
> This basically goes back to introducing global references to ActiveHand
> etc, something that really needs to be removed as well.
>
> Michael
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> On 1/13/2010 11:13 AM, Igor Stasenko wrote:
>
>> Next step is removing a direct reference to Sensor global, and replace
>> it with something like:
>>
>> self eventSensor
>
> No, that is fixing a sympton, not the problem.
> (John will love this ;-) )
>
> You would still be polling the sensor. There should be no references to
> Sensor -directly or indirectly- at all. The system should be completely
> event driven and not be allowed to ask for anything. I know it is just
> so comfortable to do this, but a very bad idea.

> This basically goes back to introducing global references to ActiveHand
> etc, something that really needs to be removed as well.
>
> Michael
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>