Do this:
- open a Transcript
- do from a Workspace Utilities cleanseOtherworldlySteppers. World clearCommandHistory. Smalltalk garbageCollect.
and see if:
- the Transcript shows that anything was removed
- the problem is still there
-- Ned Konz http://bike-nomad.com/squeak/
Yes, that did the trick! Perhaps we could add a menu item to world>help with a help bubble explaining all cases this will cure and a name which indicates something like a reset?
Do you have other tricks like this one?
Regards Martin
On Saturday 21 February 2004 12:58 am, Martin Wirblat wrote:
Perhaps we could add a menu item to world>help with a help bubble explaining all cases this will cure and a name which indicates something like a reset?
I posted a fix for the problem.
Do you have other tricks like this one?
Probably, but I never recall them and have to re-discover them.
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
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
Stef,
Depending on what you want to teach people you may go about this in either of two ways. If you are only interested in Morphic, you should *always* refer to ActiveHand - this is the only reliable way by which to query Morphic input state.
If you are interested in dual Morphic/MVC stuff "the right way" to refer to "current I/O state" is by applying a pattern which says:
(ActiveHand ifNil:[Sensor]) cursorPoint.
ActiveHand *will* be nil for MVC so this is the safe and recommended way to deal with it. And yes, it looks ugly but that's what you get from incomplete paradigm shifts...
Cheers, - Andreas
----- Original Message ----- From: "ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, February 21, 2004 7:13 PM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
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
For the first book I just want to get rid of Sensor everywhere. For the second one, I'm thinking to throw it away. But I will see. Thanks anyway. Stef
Stef,
Depending on what you want to teach people you may go about this in either of two ways. If you are only interested in Morphic, you should *always* refer to ActiveHand - this is the only reliable way by which to query Morphic input state.
If you are interested in dual Morphic/MVC stuff "the right way" to refer to "current I/O state" is by applying a pattern which says:
(ActiveHand ifNil:[Sensor]) cursorPoint.ActiveHand *will* be nil for MVC so this is the safe and recommended way to deal with it. And yes, it looks ugly but that's what you get from incomplete paradigm shifts...
Cheers,
- Andreas
----- Original Message ----- From: "ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, February 21, 2004 7:13 PM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
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
Andreas, This may be good advice, except that ActiveHand (HandMorph) does not understand shiftPressed. I'm running 'Squeak3.6'.
regards --Trygve
At 21.02.2004 19:13, you wrote:
thanks for the advice I will change everything for my book.
Stef
On 21 févr. 04, at 18:52, Andreas Raab wrote:
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
HandMorph>>shiftPressed ^lastMouseEvent shiftPressed
- A.
----- Original Message ----- From: "Trygve Reenskaug" trygver@ifi.uio.no To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, February 22, 2004 4:40 PM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
Andreas, This may be good advice, except that ActiveHand (HandMorph) does not understand shiftPressed. I'm running 'Squeak3.6'.
regards --Trygve
At 21.02.2004 19:13, you wrote:
thanks for the advice I will change everything for my book.
Stef
On 21 févr. 04, at 18:52, Andreas Raab wrote:
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
Andreas,
So when you say: "NEVER, NEVER use Sensor. DO NOT EVER USE IT! Refer to the hand instead." is this is a short way of saying: " Never use sensor. Extend HandMorph with your own code instead. "?
1) IMO, it is not a good idea to extend basic library classes in simple applications. The surface area between the evolving Squeak releases and my own applications become very large and very hard to handle. It will #^@! things up.
3) Aren't you overselling a bit when you suggest replacing Sensor with HandMorph in applications? A quick check indicates that Sensor understands 76 messages that are missing from HandMorph. Examples: #(#anyButtonPressed #anyModifierKeyPressed #blueButtonPressed #buttons #characterForKeycode: #commandKeyPressed #controlKeyPressed #createMouseEvent #currentCursor #currentCursor: #cursorPoint: #eventQueue #eventQueue: ...
Need really all of them be harmful to Morphic? I have used Sensor when I need the current state of mouse and keyboard, and events when I need the state at a certain time. Following your advice, it looks as if I have to do a lot of low-level programming to maintain contact with the input devices.
4) Finally: After a couple of hours frustrating archeology into Squeak, I wonder if a good solution could be to say
CurrentHand lastEvent shiftPressed, (or controlKeyPressed or whatever)
If this is what you meant, you could have saved me a lot of irritating work by saying so in the first place.
There are 51 messages understood by Sensor and not by either HandMorph or MouseEvent. They all seem to be state changing and it makes sense to replace Sensor by _CurrentHand_ and _CurrentHand lastEvent_ in Morphic.
cheers --Trygve
At 22.02.2004 17:15, you wrote:
HandMorph>>shiftPressed ^lastMouseEvent shiftPressed
- A.
----- Original Message ----- From: "Trygve Reenskaug" trygver@ifi.uio.no To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, February 22, 2004 4:40 PM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
Andreas, This may be good advice, except that ActiveHand (HandMorph) does not understand shiftPressed. I'm running 'Squeak3.6'.
regards --Trygve
At 21.02.2004 19:13, you wrote:
thanks for the advice I will change everything for my book.
Stef
On 21 févr. 04, at 18:52, Andreas Raab wrote:
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
--
Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway
So when you say: "NEVER, NEVER use Sensor. DO NOT EVER USE IT! Refer to the hand instead." is this is a short way of saying: " Never use sensor. Extend HandMorph with your own code instead. "?
No, it's a way of saying (and meaning ;) "NEVER, NEVER use Sensor if you write code for Morphic". You need to get your information from the hand to be a proper Morphic citizen.
- IMO, it is not a good idea to extend basic library
classes in simple applications. The surface area between the evolving Squeak releases and my own applications become very large and very hard to handle. It will #^@! things up.
Sure. What's your point?
[BTW, did I miss half of your message? You're jumping from 1) to 3) here...]
- Aren't you overselling a bit when you suggest replacing
Sensor with HandMorph in applications?
Not at all if you look at the subtlety of problems introduced (did you read the thread leading up to this post?)
Need really all of them be harmful to Morphic?
Most the messages dealing mouse and keyboard *are* harmful. What's even worse is - you can't say for sure. That's why I'm saying "get your state from the hand" and make HandMorph polymorphic enough with Sensor so people will easily recognize that the same state is available.
I have used Sensor when I need the current state of mouse and keyboard, and events when I need the state at a certain time. Following your advice, it looks as if I have to do a lot of low-level programming to maintain contact with the input devices.
If you want your app to work properly within Morphic, yes you will. But it's an exception to use input devices directly. And it's also because of being able to "easily use" input devices that I left Sensor working in the way it does. But that's entirely unrelated to the fact that "Morphic applications" should get their state from the hand unless they have reason not to. And querying for the shift state or the cursor point is NOT a reason to screw around with the way Morphic works.
- Finally: After a couple of hours frustrating archeology
into Squeak, I wonder if a good solution could be to say
CurrentHand lastEvent shiftPressed,(or controlKeyPressed or whatever)
If this is what you meant, you could have saved me a lot of irritating work by saying so in the first place.
It is not a good solution. The expression is way to long for people to remember and it exposes what should be hidden inside the hand - for a client it is irrelevant how the hand determines what its shift state is and it may or may not use the last event. A polymorphic response is really what should be in the hand including the majority of interesting/desirable information from Sensor.
Secondly, it needs to be "ActiveHand" - this is the hand in control of the current world, it's dynamic and if you don't have a hand you know about (such as from some event) ActiveHand is what you want to use.
Cheers, - Andreas
And what about the tablet methods: Sensor tabletPressure, tabletPoint, ..?, in the current image HandMorph don't receive that information.
On 23/02/2004, at 06:14, Andreas Raab wrote:
So when you say: "NEVER, NEVER use Sensor. DO NOT EVER USE IT! Refer to the hand instead." is this is a short way of saying: " Never use sensor. Extend HandMorph with your own code instead. "?
Javier Diaz-Reinoso
I answered that question already:
[...] make HandMorph polymorphic enough with Sensor so people will easily recognize that the same state is available
Cheers, - Andreas
----- Original Message ----- From: "Javier Diaz-Reinoso" javier_diaz_r@mac.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, February 23, 2004 6:06 PM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
And what about the tablet methods: Sensor tabletPressure, tabletPoint, ..?, in the current image HandMorph don't receive that information.
On 23/02/2004, at 06:14, Andreas Raab wrote:
So when you say: "NEVER, NEVER use Sensor. DO NOT EVER USE IT! Refer to the hand instead." is this is a short way of saying: " Never use sensor. Extend HandMorph with your own code instead. "?
Javier Diaz-Reinoso
hi andreas
I need your help :) about ActiveHand use instead of Sensor
HandMorph>>anyButtonPressed
^ lastMouseEvent anyButtonPressed
to give try I added that method in HandMorph and I changed my turtle code to be Turtle>>anyButtonPressed (Delay forMilliseconds: 2) wait. ^ ActiveHand anyButtonPressed
I put that in turtle just so that people do not have to type too much (note that this is clearly bad but this is another discussion related to the problem I have with morphic concurrency. I played with scratch and I understand what you meant in a previous thread)
Turtle>>wand "self new wand"
[self anyButtonPressed] whileFalse: [self go: 30 atRandom. self turnLeft: 30 atRandom]
With this code, I cannot stop the turtle to loop when I pressed on shift or any key and mouse. If I removed the delay the squeak just blocks completely.
While with Turtle>>anyButtonPressed (Delay forMilliseconds: 2) wait. ^ Sensor anyButtonPressed
The loop stops as soon as I click.
So I went down in the HandMorph I tried to register my turtle to event: in an inspector I did
ActiveHand addKeyboardListener: self
But I do not know what do I get and how I should handle that. The methods says addKeyboardListener: anObject "Make anObject a listener for keyboard events. All keyboard events will be reported to the object."
But no more. So I looked into Object to see but it seems that the event mentioned there are related to the on:send:... one
So if you can enligth me, please do it.
Stef
Am 05.03.2004 um 09:59 schrieb ducasse:
hi andreas
I need your help :) about ActiveHand use instead of Sensor
Andreas is not yet in, so I'll answer that ;-)
Turtle>>anyButtonPressed (Delay forMilliseconds: 2) wait. ^ ActiveHand anyButtonPressed
Turtle>>wand [self anyButtonPressed] whileFalse: [self go: 30 atRandom. self turnLeft: 30 atRandom]
This will not work (as you have discovered) since this piece of code runs on its own and does not give Morphic the chance to check for events, hence the button state will never change. You may have noticed that the rest of Squeak (or, more specifically, Morphic) is blocked while you execute this code.
Andreas did not say to *never* use Sensor. But certainly you should never refer to Sensor in well-behaved *Morphic* code. Your Turtle code is an example of simple "I-have-the-whole-machine-for-me" code, but it does not cooperate well with the event-driven logic of Morphic.
There are several options for you:
a) Continue to use Sensor and accept that Morphic will block while your code is running.
b) Rewrite your example to follow the Morphic philosophy. This is certainly possible, but I doubt it will exhibit the same simplicity that the "old"code has.
c) Apply a little hacker-fu to make Morphic run under your control: Turtle>>anyButtonPressed World doOneCycle. "Bert's magic hacker-fu" ^ ActiveHand anyButtonPressed This one works, since essentially Morphic runs the #doOneCycle method in a loop all day anyway. You have to be careful though to when you can call this, because I doubt Morphic is fully reentrant.
d) Write a system that allows and encourages the coding style you used (because it is so beautifully simple and almost obvious), but is actually event-driven under the hood. Your code would run quasi-parallel with all the other UI code. Tough stuff, though.
e) Do not write system d) yourself, but wait for Andreas to release it ;-)
- Bert -
Thanks bert,
Your analysis is correct. I always bump in the fact that I do not want to have a simulation system build on top of morphic (using step) but in the same time I want to have a user friendly feedback. So for me Morphic is a bit doomed regarding that (I got the same problem with my bot system)
There are several options for you:
a) Continue to use Sensor and accept that Morphic will block while your code is running.
b) Rewrite your example to follow the Morphic philosophy. This is certainly possible, but I doubt it will exhibit the same simplicity that the "old"code has.
c) Apply a little hacker-fu to make Morphic run under your control: Turtle>>anyButtonPressed World doOneCycle. "Bert's magic hacker-fu" ^ ActiveHand anyButtonPressed
Ok I will try this one. I always thought that it was bad to use World doOneCycle. but you are right.
This one works, since essentially Morphic runs the #doOneCycle method in a loop all day anyway. You have to be careful though to when you can call this, because I doubt Morphic is fully reentrant.
d) Write a system that allows and encourages the coding style you used (because it is so beautifully simple and almost obvious), but is actually event-driven under the hood. Your code would run quasi-parallel with all the other UI code. Tough stuff, though.
oh yes, especially when you only have the nitgh to code it and hate concurrency. I compared my turtle code to the one of nathanael doing animation and I was really afraid I could not bug fix it. :)
e) Do not write system d) yourself, but wait for Andreas to release it ;-)
I know. I may port everything to tweak once released. But I want that my wife can work meanwhile and finiiiiiisssssshhhhhh this @#$%^&*()_book
****Thanks****
Am 05.03.2004 um 12:37 schrieb ducasse:
I always thought that it was bad to use World doOneCycle.
It is bad. You should not teach that in your book. Teaching to use Sensor is far better in this context, especially if you mention that things are done differently under Morphic.
- Bert -
Hi Stef,
You're hitting the wall with regards to what Morphic can do and what it cannot. IOW, your little example is precisely one of those "simple things" that I referred to which are so hard to do with Morphic. In such a situation your only choice is to go directly to Sensor.
With regard to the listeners, all events to the listener are sent via #handleListenEvent: (so this would be the place to start looking at) but notice that this wouldn't help you in the above. The hand simply won't get any events while you're "blocking" in the delay.
Cheers, - Andreas
----- Original Message ----- From: "ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, March 05, 2004 9:59 AM Subject: Re: Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
hi andreas
I need your help :) about ActiveHand use instead of Sensor
HandMorph>>anyButtonPressed
^ lastMouseEvent anyButtonPressed
to give try I added that method in HandMorph and I changed my turtle code to be Turtle>>anyButtonPressed
(Delay forMilliseconds: 2) wait. ^ ActiveHand anyButtonPressed
I put that in turtle just so that people do not have to type too much (note that this is clearly bad but this is another discussion related to the problem I have with morphic concurrency. I played with scratch and I understand what you meant in a previous thread)
Turtle>>wand "self new wand"
[self anyButtonPressed] whileFalse: [self go: 30 atRandom. self turnLeft: 30 atRandom]
With this code, I cannot stop the turtle to loop when I pressed on shift or any key and mouse. If I removed the delay the squeak just blocks completely.
While with Turtle>>anyButtonPressed
(Delay forMilliseconds: 2) wait. ^ Sensor anyButtonPressed
The loop stops as soon as I click.
So I went down in the HandMorph I tried to register my turtle to event: in an inspector I did
ActiveHand addKeyboardListener: self
But I do not know what do I get and how I should handle that. The methods says addKeyboardListener: anObject "Make anObject a listener for keyboard events. All keyboard events will be reported to the object."
But no more. So I looked into Object to see but it seems that the event mentioned there are related to the on:send:... one
So if you can enligth me, please do it.
Stef
Wanna Tweeaaaaakk :)
You're hitting the wall with regards to what Morphic can do and what it cannot. IOW, your little example is precisely one of those "simple things" that I referred to which are so hard to do with Morphic. In such a situation your only choice is to go directly to Sensor.
Ok. I know I always have idiot dead simple code but it just requires stuff that is not there. Ok I will then continue with what I have. I always feel like a dummy and I hate that.
Stef
With regard to the listeners, all events to the listener are sent via #handleListenEvent: (so this would be the place to start looking at) but notice that this wouldn't help you in the above. The hand simply won't get any events while you're "blocking" in the delay.
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
ducasse -
Javier Diaz-Reinoso -
Martin Wirblat -
Ned Konz -
Trygve Reenskaug