The checkout for the tests used commit 5fa5f0c which is a merge with the ‘dev’ branch, presumably because I had forgotten to change the base branch to ‘Pharo12’ when opening this pull request.

I closed and reopened, the checkout for the tests now used commit f6a7a23 which is a merge with the ‘Pharo12’ branch as expected.

(A bit OFFTOPIC:) @Rinzwind do you have an opinion on BlPhysicalDisplaySize? I doubt about its existence... I'm not clear why not using 'Point'.

As an exercise I rewrote a method in this PR as:

	^ SystemVersion current major >= 12
		ifTrue: [
			| canvasScaleFactor |
			canvasScaleFactor := OSWorldRenderer canvasScaleFactor.
			BlPhysicalDisplaySize
				width: (spaceHostMorph width * canvasScaleFactor)
				height: (spaceHostMorph height * canvasScaleFactor) ]
		ifFalse: [
			BlPhysicalDisplaySize
				width: spaceHostMorph width
				height: spaceHostMorph height ]

... at the end, BlPhysicalDisplaySize is the same as Point.

I’m not entirely sure I understand the question about BlPhysicalDisplaySize, I tried just removing the send of #asPhysicalSize from #physicalSize on BlMorphicHostSpace so that it answers a Point instead of a BlPhysicalDisplaySize, but that causes an error when opening the Bloc Demo Browser (“Instance of Point did not understand #width” in #scaleFactor on BlMorphicHostSpace).

Some context. At some moment of the history of Bloc (that I ignore) this hierarchy was introduced:

It provides API to convert values with scale factors. So, @Rinzwind is in the domain of the problem you attacked with this feature, both in Pharo morphic and now in Bloc.

But I find not much sense on these classes, and I wonder if we remove them. Or we improve so they start to make sense. I asked your opinion because maybe you had some comments either in favor or against these classes.

This test shows its usage (BlDisplayPositionsTest>>#testAsPhysical):

testAsPhysical

	| aLogicalPosition aPhysicalPosition |
	aLogicalPosition := BlLogicalDisplayPosition fromPoint: 100 @ 200.
	aPhysicalPosition := aLogicalPosition asPhysical: 2.
	self assert: aPhysicalPosition asPoint equals: 200 @ 400.

e.g.:
There is a logical point (100, 200) but the physical device has a scale factor 2, then the API helps converting to (200, 400)... but do we need this help?

Maybe if the physical device is modeled as a new class BlPhysicalDevice, that has the scale factor inside. And the BlPhysicalPositions can have a reference to the device. Then the knowledge about what is the scale factor can be into an object that models a physical device. There can be also a subscription API so you receive a message when the device changes the scale factor and you act in consequence (e.g. refresh the BlSpace).

I’m not sure I can really help answer this question, but I can see benefit to having different classes for representing a position versus a size, and representing a scaled position or size versus one that is not scaled. When all four are represented as a plain Point, it can get confusing to keep track of which is which, especially when one can’t easily tell from the name of the variable the Point is contained in. Looking at the number of references to the classes and the senders of #asLogical: and #asPhysical: it however seems these distinctions aren’t used all that much so I can also see why you might prefer to drop them altogether.