[squeak-dev] (UndefinedObject doesNotUnderstand: #selectionRects) when selecting a Font via ctrl+k

Marcel Taeumel marcel.taeumel at hpi.de
Wed Apr 27 12:09:31 UTC 2022

Hi Nicolas --

> Shouldn't every un-protected paragraph inst.var. access be replaced with self paragraph?

There are a lot of ifNil checks against paragraph in TextMorph. I suppose this is to not invalidate-and-recompute paragraphs by accident, which would further slow down the overall input experience.

In #handleInteraction:fromEvent:, I can see two invariants:

1. The instVar paragraph must never be nil when entering the method.
2. Any "new" paragraph must be processed after "interactionBlock" so that visual glitches regarding the text selection can be avoided.

Thus, replacing all accesses to the instVar "paragraph" with the accessor #paragraph seems too risky performance-wise. For now, I will make sure that the paragraph is notNil after the interactionBlock.

Am 25.04.2022 23:43:45 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Shouldn't every un-protected paragraph inst.var. access be replaced with self paragraph?

Le lun. 25 avr. 2022 à 23:40, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]> a écrit :

On MacOS, in a workspace, cmd+k invokes a FontChooser that works well, but ctrl+k invokes a simpler list chooser dialog Moprh that works less well.

If I select another font in this dialog, I got the MNU from within: TextMorphForEditView>>handleInteraction:fromEvent:, because paragraph is (temporarily) set to nil

Note that once the Debugger opens, the paragraph inst.var. is reset to a NewParagraph.
Also note that oldParagrah temporary is a NewParagraph which kind of funny.

When I inspect paragraph inst.var.ref., I see half are protected the ifNotNil: check, half not... The kind of state mutations leaving traps on the track.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220427/69ddae07/attachment.html>

More information about the Squeak-dev mailing list