[Cuis-dev] Morphic3 at work

Hilaire Fernandes hfern at free.fr
Sun Sep 14 01:58:14 PDT 2025


On the paper, there are no notion of line nor intersection as in DrGeo.

The straight lines the user draws with the tools are just plain writing 
in the paper constrained by the tool (line6):

1
2
3
4
5
6
7
8

	

GeometryTool>>mouseButton1Down: event localPosition: localPosition
	(self paper writingTool notNil and: [self inStrokeZone: localPosition])
		ifTrue: [" initiate stroke along the tool "
			lastHandPosition := nil.
			" Let the paper to handle the hand stroke, constraint the hand position 
to be aligned with a tool border ! "
			self paper mouseButton1Down: event localPosition: (self externalize: (self constrainToDirection: localPosition))]
		ifFalse: ["Initate a drag of the tool " 
			lastHandPosition := self externalize: localPosition ]



There are notion of stroke zone (line 1 above), specific to each tool 
(SetSquare below):

1
2
3
4
5
6
7
8
9

	

SetSquare>>inStrokeZone: localPosition
	(self strokeZoneX containsPoint: localPosition)ifTrue: [
		strokeSide := #ox.
		^ true].
	(self strokeZoneY containsPoint: localPosition)ifTrue: [
		strokeSide := #oy.
		^ true].
	strokeSide := nil.
	^ false


Then, the specific constraint for a given tool as the SetSquare:

1
2
3
4

	

SetSquare>>constrainToDirection: localHandPosition
	^ strokeSide == #ox
		ifTrue: [localHandPosition x @ 0]
		ifFalse: [0 @ localHandPosition y]


Again, the Morphic3 framework proved to be of an invaluable assistance 
in such design. Even Juan did not realize its usefulness until recently, 
so far for him the Morphic protocol to navigate from one reference frame 
to another one was only useful for internal usage, not particularly 
intended to the GUI designer. It proved the opposite and it reminds me 
this Alan Kay quote: /Simple things should be simple and complex things 
should be possible./ This is exactly where we are with Morphic3.

Regarding snapping with line shapes, it should be doable. Indeed the 
handwritings in a paper are grouped in StrokeGroupMorph (it manages the 
writing occurring between a pen down and pen up gesture). Such groups 
could self analyze themselves to recognize usual shapes as straight 
line, circle. Then, you could have a cross analysis between such groups 
to identify the intersections between them. Perfectly doable. When you 
have these information available, snapping to a given tool is easy. The 
evil is in the details of course.

There are snapping between the ruler and the set square. In the demo, 
you can observe the set square aligns itself with he ruler when it is 
moved toward it and the two are more or less parallel.

Dybo targets all kind of teaching in school. In math, the geometry tools 
are the minimum to have, I will implement the compass tool next. 
Snapping is kind of very cool to have to attract the attention of math 
teachers, but I need first to develop other tooling for other taught 
subject. The geometry tools are special because they are used to sketch 
on the paper, the other tool to develop would be different, easier to 
implement. These are dynamic knowledge models represented by a box morph 
and scripted with smalltalk code edited by the user (teacher or 
student). The aim is high indeed.

Hilaire

Le 14/09/2025 à 09:06, Luciano Notarfrancesco a écrit :
> Very cool! Do the tools snap to lines, intersections, etc?

-- 
http://mamot.fr/@drgeo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250914/1720e2c6/attachment-0001.htm>


More information about the Cuis-dev mailing list