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 -
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 :)
Actually I meant this section:
http://producingoss.com/en/bug-tracker-usage.html
(though the rest of the book is good too)
- Bert -
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 bert@freudenbergs.dewrote:
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 :)
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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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 -
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 bert@freudenbergs.dewrote:
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@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
karl ramberg