[Pharo-project] 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
2010/1/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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. ...
I don't remember my original idea, but i offered to replace such uses by something like: Sensor captureEventsDuring: aBlock where block should accept a single event, and it should stay captured until block returns false, i.e.: Sensor captureEventsDuring: [:ev | "handle the event here" ev anyButtonPressed "keep looping if any mouse button still held" ]. Next step is removing a direct reference to Sensor global, and replace it with something like: self eventSensor
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
thanks mike I realllllly want to clean that part too. And we will do it. This is why I need a bit of supervision and time. Stef On Jan 13, 2010, at 11:20 AM, Michael Rueger wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/13 Michael Rueger <m.rueger@acm.org>:
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.
Totally agree with you. But removing it from use, means changing the logic in places where it using it. And given that you got 166 refs to Sensor.. imagine what amount of work it means. So, see my proposal as an intermediate(transitional) step.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Igor Stasenko -
Michael Rueger -
Stéphane Ducasse