[Cuis-dev] Question about LayoutMorph and overlapping fullBoundsInOwner

[Juan Vuletich]

Hi Folks,

On 4/3/2025 2:03 PM, Mark Volkmann via Cuis-dev wrote:
> On Thu, Apr 3, 2025 at 11:54 AM Nicolás Papagna Maldonado 
> <nicolas.papagna at gmail.com <mailto:nicolas.papagna at gmail.com>> wrote:
>
>     Hi Mark!
>
>     On Thu, Apr 3, 2025 at 1:29 PM Mark Volkmann
>     <r.mark.volkmann at gmail.com <mailto:r.mark.volkmann at gmail.com>> wrote:
>
>         I'm thinking that "one ends where the next one starts" does
>         not mean they overlap.
>         I guess you could say they share a border.
>
>     Yup, that's what I meant. They do not share a border, but their
>     fullBoundsInOwner imply they do.
>
>         I did the following to make it more clear:
>
>         box1 := BorderedBoxMorph new morphExtent: 100 at 100;
>         borderColor: Color yellow; borderWidth: 2.
>         box2 := BorderedBoxMorph new morphExtent: 100 at 100;
>         borderColor: Color red; borderWidth: 2.
>         layout := LayoutMorph newColumn addMorph: box1; addMorph: box2.
>         layout openInWorld.
>
>
>     Thanks for the example!
>     I used a 20px border to make it more visible.
>
>     image.png
>
>     They don't share a border looking at fullBoundsInOwner it looks
>     like they do: one ends at y=100 (100 at 100) and the next one starts
>     at y=100 (0 at 100).
>     Would't this imply that their extent is 101 at 101 px wide?
>
>     box1 fullBoundsInOwner ======> 0 at 0 corner: 100 at 100 .
>     box2 fullBoundsInOwner =======>  0 at 100 corner: 100 at 200 .
>
>
> I don't think so.
> If you think of the numbers like pixels, you could interpret 0 to 100 
> to mean occupying the pixels at 0, 1, 2, ..., 100 which is 101 pixels.
> But if you think of the numbers like measurements then 100 - 0 is 100, 
> not 101.
>
> -- 
> R. Mark Volkmann
> Object Computing, Inc.

The convention used in class Rectangle is that they include the origin 
but not the corner. See for instance #containsPoint: . This has been 
like this since Smalltalk-80, and most likely since earlier. This 
convention is consistent with considering pixels discrete (like square 
tiles). Then `0 at 0 corner: 100 at 100` will have width = 100 and cover 
exactly 100 pixels wide. I do not like this convention at all.

In Cuis' Morphic, coordinates are _not_ integers. They are floating 
point, and they are to be interpreted as Mathematical Points in the Real 
Plane. Then, pixels are not "square tiles" but samples in a continuous 
space (zero size Mathematical Points in the Real Plane). But a lot of 
Smalltalk-80 lives in Cuis, and for instance, BitBlt uses Rectangles.

So, in Cuis, instances of Rectangle are only used to despict pixel areas 
on the Display (like clippingRects), and use the ST-80 convention. And I 
think they should only be used for that. Geometry in the Real Plane 
should use instances of other classes. Removing this from Cuis would 
require completely removing class Rectangle. Having a class Rectangle 
that is incompatible with ST-80's and Squeak's would only mean confusion 
and pain.

Note that Point doesn't have a problem. It can be used in code adhering 
to either convention.

Now I think this should be part of the Rectangle class comment.

Hope this helps,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250411/f955a51b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5427 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250411/f955a51b/attachment-0001.png>