Event Theatre issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Event Theatre issue

Bert Freudenberg
On 02.11.2011, at 14:15, Derek O'Connell (JIRA) wrote:

>   [ http://tracker.squeakland.org/browse/SQ-998 ]
>
> Derek O'Connell commented on SQ-998:
> ------------------------------------
>
> Karl, color picker? Do you mean the button, PaintBoxColorPicker, or PaintBoxMorph>>eyedropper:action:cursor:evt: ? I have still to digest SketchEditorMorph>>mouseMove: but it mentions "eventRecorders", although I admit to finding the code a little tortuous so maybe there is a simpler solution.


Please don't use the bug tracker for discussions (*). That's what the mailing list is for :)

Basically, any direct reference to Sensor circumvents the Morphic event processing. It is from the old MVC days. The only legal usage is in HandMorph, which needs to read events from Sensor.

So there are a couple of offenders:

        SystemNavigation default browseAllSelect: [:m |
                (m hasLiteralThorough: #Sensor)
                and: [m methodClass inheritsFrom: Morph] ]

PaintBoxMorph>>eyedropper:action:cursor:evt: is one of them, as is PasteUpMorph>>chooseClickTarget (which is used to select players).

- Bert -

(*) http://producingoss.com/en/bug-tracker.html
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Event Theatre issue

Bert Freudenberg

On 02.11.2011, at 15:41, Bert Freudenberg wrote:

> Please don't use the bug tracker for discussions (*). That's what the mailing list is for :)
>
> (*) http://producingoss.com/en/bug-tracker.html

Actually I meant this section:

        http://producingoss.com/en/bug-tracker-usage.html

(though the rest of the book is good too)

- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Event Theatre issue

Karl Ramberg
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
                ].

But there are some quite weird code issues because both ColorPickerMorph and PaintBoxMorph do color tracking here. 

Karl

On Wed, Nov 2, 2011 at 6:00 PM, Bert Freudenberg <[hidden email]> wrote:

On 02.11.2011, at 15:41, Bert Freudenberg wrote:

> Please don't use the bug tracker for discussions (*). That's what the mailing list is for :)
>
> (*) http://producingoss.com/en/bug-tracker.html

Actually I meant this section:

       http://producingoss.com/en/bug-tracker-usage.html

(though the rest of the book is good too)

- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Event Theatre issue

Bert Freudenberg
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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Event Theatre issue

Karl Ramberg
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 I mentioned.

Karl


On Wed, Nov 16, 2011 at 12:43 PM, Bert Freudenberg <[hidden email]> 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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev