[etoys-dev] Event Theatre issue
karlramberg at gmail.com
Thu Nov 17 15:55:19 EST 2011
You are right. I'm not totally on top of the issue though.
But as a quick fix to make the recorder work at all we could use the change
On Wed, Nov 16, 2011 at 12:43 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> On 15.11.2011, at 22:28, karl ramberg wrote:
> So I looked at the code in PaintBoxMorph>>eyedropper:action:cursor:evt:
> I see that it uses Sensor and just updates the display.
> If we do as in ColorPickerMorph and use ActiveWorld doOneCycle instead I
> think we can track the events in EventTheatre.
> [Sensor anyButtonPressed] whileTrue:
> [ pt := Sensor cursorPoint.
> "the hand needs to be drawn"
> evt hand position: pt.
> +ActiveWorld doOneCycle.
> -self world displayWorldSafely.
> -delay wait
> It shouldn't use Sensor at all. No Morphic code should access Sensor
> (except HandMorph which fetches events). It always comes back biting us.
> It should use HandMorph, or at least fetch events in a way that is
> compatible with EventTheater recording and playback.
> But there are some quite weird code issues because both ColorPickerMorph
> and PaintBoxMorph do color tracking here.
> The point of the low-level loop using Sensor is to prevent regular Morphic
> event processing. That's why it sets the hand position directly, and
> redraws it.
> If you call doOneCycle, that does a full Morphic cycle, including event
> processing, running steppers, etc. The hand's position would be set
> automatically by that. But indeed it may lead to "weird issues". The
> method comment says "Take total control" and avoiding "weird issues"
> seems like a good reason for that ;)
> The simplest way to make this work might be replacing the Sensor access
> like this:
> Sensor cursorPoint ==> evt hand position
> Sensor anyButtonPressed ==> evt hand lastEvent anyButtonPressed
> Additionally, the hand's position needs to be updated, but without further
> event processing. Normally the hand's position is set in
> HandMorph>>handleEvent: which handles the event generated by
> HandMorph>>processEvents which is called in each world cycle. Instead, we
> would need a method in HandMorph that only creates events and updates its
> own position. It also would need to make sure EventTheater records this
> (not sure how that's implemented). HandmorphForReplay would need to
> implement the same method but reading events from its tape instead of
> accessing Sensor.
> Problem is that all accesses to Sensor need to be checked and changed
> accordingly, if only half the code involved is converted I can imagine more
> weird things happening ;^) So at least ColorPickerMorph and PaintBoxMorph
> would both need to be cleaned up in one go.
> - Bert -
> etoys-dev mailing list
> etoys-dev at squeakland.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev