[squeak-dev] I've reached my limits

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Apr 17 14:39:00 UTC 2021


Hi Marcel, thanks for the explanations.
The sole purpose of halt was indeed to check at which depth the handler
would be activated.
This gave me a clue about the possibility or not to detect interception by
just stepping (how deep at worse would I have to step into).
Another alternative that I did not try out would have been to step in two
debuggers in parallel,
one with the red or yellow event, the other with blue...

Le sam. 17 avr. 2021 à 14:51, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

> Hi Nicolas,
>
> I fixed this bug in MorphicTests-mt.77 by disabling "Morph haloForAll".
>
> Well, I think that event handling in Morphic has a conceptual complexity
> that is comparable to other (non-Smalltalk) UI frameworks. Events travel
> through the hierarchy of morphs, starting in the world. Only one morph can
> be the actual handler. Event filters might intercept this, do something
> different, and tell the mechanism to further ignore the event.
>
> In this test03EventHandler, the question was why that event did not reach
> its destination (here: that block in the test method). Of course, "self
> halt" does not work when a destination is not reached.
>
> Why might an event not reach the desired handler (morph):
> a) the target handler omits to reply to #handlesMouseDown: (etc.)
> b) another (maybe sibling) morph is on top of it
> c) the morph is not even in the hand's world
> d) an event filter intervenes and marks the event as "ignored"
>
> The cases a), b), and c) can easily be checked through the debugger. The
> world and the entire morph hierarchy is easily accessible. Bounds can be
> checked against the event's position.
>
> This leaves case d), which is quite tricky to debug. Well, one can try to
> figure out, which implementor of #filterEvent:for: is the culprit. There
> are only 13 in the current Trunk. This path might lead to success. :-)
>
> But I think we can do better. That's why I made it possible to log
> event-ignoring coming from arbitrary event filters in the hand (morph) we
> use in the event tests. The log includes short stacks to figure out the
> actual event filter. Here is an example for this bug:
>
>
>
> While I did immediately recalled that "blue button fails" means "halo got
> the event" because I did something to the halo dispatcher in the last
> weeks, this is typically unclear for the average programmer, who is jumping
> between domains (and classes/packages) in the entire image. SO! By
> inspecting the "eventsIgnored" through the debugger, one can easily see
> both "mouseDown blue" and "PasteUpMorph >> tryInvokeHalo:" as the culprit.
>
> That's why disabling the halo during this test solves the issue.
>
> Best,
> Marcel
>
> Am 17.04.2021 13:43:08 schrieb Taeumel, Marcel <marcel.taeumel at hpi.de>:
> My bad. I will take a look at it. Maybe I also find a way to improve
> documentation and code. I will keep you posted.
>
> Marcel
> ------------------------------
> *From:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> on
> behalf of Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> *Sent:* Saturday, April 17, 2021 12:12:05 AM
> *To:* The general-purpose Squeak developers list <
> squeak-dev at lists.squeakfoundation.org>
> *Subject:* [squeak-dev] I've reached my limits
>
> I often recommend using the debugger in order to acquire a better
> understanding of code.
> A priori, I think that no bug can resist a thorough analysis/best efforts.
>
> A posteriori, it seems that I've reached my limits with the debugging
> of test03EventHandler.
> If you find where the blue button down event is filtered/catched
> without prior knowledge of Morphic event handling, by just stepping,
> then either you are lucky, or your analytical capabilities are
> tremendous (you can probably focus on 77 symbols simultaneously rather
> than the average of 7)!
> For me, that's not the right angle of attack!
>
> All I acquired is an increased reluctance to start a deeper learning
> of Morphic, more questioning about whether I'm becoming too old, and
> the conviction that things are maybe getting too complex (more than
> strictly necessary?).
>
> Look at the full stack (which BTW is not the full stack -- and more
> not shown --).
>
> I let the test03EventHandler fix to people with prior knowledge, not
> only because I was distracted by debugger bugs...
>
> Nicolas
>
> --- The full stack ---
> MorphicEventTests(Object)>>halt
> [] in MorphicEventTests>>test03EventHandler
> EventHandler>>send:to:withEvent:fromMorph:
> EventHandler>>mouseDown:fromMorph:
> Morph>>mouseDown:
> Morph>>handleMouseDown:
> MouseButtonEvent>>sentTo:
> Morph>>handleEvent:
> MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:
> [] in MorphicEventDispatcher>>dispatchMouseDown:with:
> FullBlockClosure(BlockClosure)>>ensure:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> Morph>>processEvent:using:
> Morph>>processEvent:
> [] in MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf:
> Array(SequenceableCollection)>>do:
> PasteUpMorph(Morph)>>submorphsDo:
> MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf:
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:
> [] in MorphicEventDispatcher>>dispatchMouseDown:with:
> FullBlockClosure(BlockClosure)>>ensure:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> PasteUpMorph(Morph)>>processEvent:using:
> [] in PasteUpMorph>>processEvent:using:
> [] in ActiveWorldVariable class(DynamicVariable class)>>value:during:
> FullBlockClosure(BlockClosure)>>ensure:
> ActiveWorldVariable class(DynamicVariable class)>>value:during:
> [] in ActiveWorldVariable class>>value:during:
> FullBlockClosure(BlockClosure)>>ensure:
> ActiveWorldVariable class>>value:during:
> PasteUpMorph>>becomeActiveDuring:
> PasteUpMorph>>processEvent:using:
> PasteUpMorph(Morph)>>processEvent:
> HaloMorph(SimpleHaloMorph)>>mouseDown:
> HaloMorph>>mouseDown:
> HaloMorph(Morph)>>handleMouseDown:
> MouseButtonEvent>>sentTo:
> HaloMorph(Morph)>>handleEvent:
> MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:
> [] in MorphicEventDispatcher>>dispatchMouseDown:with:
> FullBlockClosure(BlockClosure)>>ensure:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> HaloMorph(Morph)>>processEvent:using:
> MorphicEventDispatcher>>doProcessingForFocusEvent:with:
> MorphicEventDispatcher>>dispatchFocusEventFully:with:
> MorphicEventDispatcher>>dispatchFocusEventAllOver:with:
> HaloMorph(SimpleHaloMorph)>>processFocusEvent:using:
> HaloMorph(Morph)>>processFocusEvent:
> [] in [] in [] in
> HandMorphForEventTests(HandMorph)>>sendFocusEvent:to:clear:
> [] in ActiveEventVariable class(DynamicVariable class)>>value:during:
> FullBlockClosure(BlockClosure)>>ensure:
> ActiveEventVariable class(DynamicVariable class)>>value:during:
> [] in ActiveEventVariable class>>value:during:
> FullBlockClosure(BlockClosure)>>ensure:
> ActiveEventVariable class>>value:during:
> MouseButtonEvent(MorphicEvent)>>becomeActiveDuring:
> [] in [] in HandMorphForEventTests(HandMorph)>>sendFocusEvent:to:clear:
> [] in ActiveHandVariable class(DynamicVariable class)>>value:during:
> -- and more not shown --
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210417/8048c78e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 71703 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210417/8048c78e/attachment-0001.png>


More information about the Squeak-dev mailing list