On Friday 27 February 2004 1:04 pm, Frank Caggiano wrote:
> (do we have RFC's in squeak?)

I think you've just written one.

> When a morph is dropped into a world and if it has a step method the
> world starts stepping the morph (calling the morphs step method). This
> is true even if prior to the drop the morph wasn't stepping and even if
> a stopStepping message had been sent.
>
> (see Morph>>justDroppedInto:event:)
>
> Besides being a poor design choice it seems redundant. If a morph is
> stepping when it is picked up it continues to step, picking up the morph
> doesn't stop it from stepping.

It's redundant. Even more redundant are the calls to arrangeToStartStepping:.

If you create a morph, add it to the world, pick it up, and set it down:

the morph and its submorphs will have been sent arrangeToStartStepping: four 
times.

Yes. I added instrumentation to WorldState, and did this:

m _ MorphExample new.
m allMorphs asArray collect: [ :s | s valueOfProperty: #startSteppingCount ].
  => #(nil nil)
m openInWorld.
m allMorphs asArray collect: [ :s | s valueOfProperty: #startSteppingCount ].
  => #(nil 2 2)
m grabWithHand.
m allMorphs asArray collect: [ :s | s valueOfProperty: #startSteppingCount ].
  => #(2 2)
"then drop it"
m allMorphs asArray collect: [ :s | s valueOfProperty: #startSteppingCount ]. 
  => #(4 4)
m delete.

> It's a poor design choice because if, for example,  I have a morph that
> moves from its starting position to some other position via step, then
> stops due to some event, that sequence shouldn't be triggered by the
> user rearranging her desktop. And while it's possible to work around
> this by overriding Morph>>whatsSteps it just that, a work around.
>
> If the state of the morph's stepping needs to be know when it is dropped
> worldState keeps a list of stepping morphs. But again I don't see why
> this is needed because the morph's stepping state isn't changed by being
> picked up.

Right. Actually, there's only a couple of situations where a (generic) morph 
*isn't* potentially stepping; one is after duplication from a parts bin or 
halo, and one is when the morph has been freshly created.

noteNewOwner:
	does nothing

intoWorld:
	calls wantsSteps, which looks for a step method before Morph

acceptDroppingMorph:event:
	into World
		calls addMorphFront:
			which calls intoWorld: if world was different
				which calls startStepping: if wantsSteps is true
					which also starts any submorphs that want steps
			then calls startSteppingSubmorphsOf:
				which also arranges to start any submorphs that want steps
	into other PU morph
		calls startSteppingSubmorphsOf: (why?)

justDroppedInto:event:
	calls startSteppingSubmorphsOf: (why?)
	

I posted a change set a while ago that reduces the amount of unnecessary 
garbage created on the redundant startStepping: calls, but this should 
probably be looked at.

Specifically, I think that we ought to consider moving the startStepping into 
one of the Morph notification calls that we now have (noteNewOwner: or 
intoWorld:).

In the new Connectors I've stopped using #step altogether, since it's also 
used by eToys to step scripts. I use a different method for my own private 
stepping, which isn't affected by all these startStepping calls.

That is, I use:

	self startStepping: #someSelector at: scheduledTime arguments: args stepTime: 
stepTime

or
	self startStepping: #someSelector

(which starts now, and calls stepTime to get the step time)

and
	self stopStepping: #someSelector

-- 
Ned Konz
http://bike-nomad.com/squeak/