Oh thanks, that explains the problem I observed and why I did not spot the bug
in all the time I spent staring at it in the debugger: the values were there in
the rectangle, only swapped between origin and corner!
Maybe receiving a rectangle as the second argument of #fractions:offsets:
should
Hi David,
this is the bug with LayoutFrame>>#fractions:offsets: we were talking
about relative to that class comment.
In Pharo, Rectangles are constrained to have the smallest vertical value
as the top, smallest horizontal value as the left, largest vertical
value as bottom and largest horizonta
I guess that is a class comment for LayoutFrame. I think this is great
improvement.
By I the way, I noticed something really strange when I was using it in my
learning project of a TicTacToe game. I started initializing a LayoutFrame
using #fractions:offsets:, but I had strange incorrect result
I define a transformation frame relative to some rectangle. I'm basic
data structure used for graphics.
I represent two groups of distances:
- The fractional distance (between 0 and 1) to place the morph in its
owner's bounds
- Fixed pixel offset to apply after fractional positioning (e.g., "10
