Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)

ducasse ducasse at iam.unibe.ch
Sat Feb 21 18:13:12 UTC 2004


thanks for the advice I will change everything for my book.

Stef

On 21 févr. 04, at 18:52, Andreas Raab wrote:

> Hi Guys,
>
> The problem which has been described previously in this thread ](again)
> raises the issue of referring directly to Sensor instead of the hand 
> while
> being in Morphic. I could track the problem (thanks for the 
> description btw)
> to a TransferMorph which kept stepping all the time due to an error in 
> the
> drop handling method (I presume this is what Ned's fix addresses).
>
> However, the stepping transfer morph is not the "real cause" of the 
> problem.
> What is more problematic is the code saying:
>
> TransferMorph>>step
>     self shouldCopy: Sensor shiftPressed.
>     self updateCopyIcon
>
> It's the use of "Sensor" that screws up as you can see if you simply 
> open a
> TransferMorph in the world via "TransferMorph new openInWorld" (this 
> will
> expose precisely the same behavior that was described earlier). Why is 
> this?
>
> Historically, Sensor was (and is) being used to query for "current" 
> state of
> the input device (such as in the above #shiftPressed query) but Morphic
> assumes that *it* will be able to query for all events from the Sensor 
> via
> #nextEvent. In order to reconcile the two regimes I decided to make 
> Sensor
> drain the event queue if you issue one of these requests to Sensor. 
> This
> decision came from wanting to be able to write "simple code" such as 
> in the
> examples where we may use, e.g.,
>
> theWorldsSimplestDrawingProgram
>
>     | canvas lastPt nextPt |
>     canvas := Display getCanvas.
>     Sensor waitButton.
>     lastPt := Sensor cursorPoint.
>     [Sensor anyButtonPressed] whileTrue:[
>         nextPt := Sensor cursorPoint.
>         canvas line: lastPt to: nextPt width: 1 color: Color black.
>         lastPt := nextPt.
>     ].
>
> The trouble is that you simply cannot write such "simple code" via 
> Morphic
> (you would have to make a Morph, add a #mouseDown, #mouseMove, #mouseUp
> method etc). If Sensor's behavior would have been made to report back 
> "the
> last state known to Morphic" the code wouldn't work (Sensor would 
> always
> report the same state since Morphic will not be able to query new 
> events).
> At the same time, relaying the events recorded during this period to 
> Morphic
> after the code is finished would lead to lots and lots of weird things
> happening. That's why *ANY* request for Sensor state will drain the 
> event
> queue.
>
> What that means for something like TransferMorph's #step method is that
> *all* events which were received before that particular query are being
> thrown away. And of course, there may very well be a #mouseUp event in 
> there
> which leads to the problems people have been reporting.
>
> The bottom line of this is: If you are programming for Morphic, NEVER, 
> NEVER
> use Sensor. DO NOT EVER USE IT! Refer to the hand instead. Changing
> TransferMorph>>step to say:
>
> step
>     self shouldCopy: ActiveHand shiftPressed.
>
> entirely eliminates that problem (regardless of any error handler). 
> Again,
> if you write code for Morphic DO NOT REFER TO SENSOR! It will just #^@!
> things up.
>
> Cheers,
>   - Andreas
>
>




More information about the Squeak-dev mailing list