<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Folks,<br>
    <br>
    On 4/3/2025 2:03 PM, Mark Volkmann via Cuis-dev wrote:
    <blockquote
cite="mid:CAFfRWnVjZ0GR3HZQKeTSgkX2L+KFvct1s8uYvOvb7fAg8ZJk6Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div dir="ltr">On Thu, Apr 3, 2025 at 11:54 AM Nicolás Papagna
          Maldonado <<a moz-do-not-send="true"
            href="mailto:nicolas.papagna@gmail.com">nicolas.papagna@gmail.com</a>>
          wrote:<br>
        </div>
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote" style="margin: 0px 0px 0px
            0.8ex; border-left: 1px solid rgb(204, 204, 204);
            padding-left: 1ex;">
            <div dir="ltr">
              <div dir="ltr">Hi Mark!
                <div><br>
                </div>
              </div>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Thu, Apr 3, 2025 at
                  1:29 PM Mark Volkmann <<a moz-do-not-send="true"
                    href="mailto:r.mark.volkmann@gmail.com"
                    target="_blank">r.mark.volkmann@gmail.com</a>>
                  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin: 0px 0px
                  0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);
                  padding-left: 1ex;">
                  <div dir="ltr">I'm thinking that "one ends where the
                    next one starts" does not mean they overlap.
                    <div>I guess you could say they share a border.</div>
                  </div>
                </blockquote>
                <div>Yup, that's what I meant. They do not share a
                  border, but their fullBoundsInOwner imply they do. </div>
                <blockquote class="gmail_quote" style="margin: 0px 0px
                  0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);
                  padding-left: 1ex;">
                  <div dir="ltr">
                    <div>I did the following to make it more clear:</div>
                    <div><br>
                    </div>
                    <div>box1 := BorderedBoxMorph new morphExtent:
                      100@100; borderColor: Color yellow; borderWidth:
                      2.<br>
                      box2 := BorderedBoxMorph new morphExtent: 100@100;
                      borderColor: Color red; borderWidth: 2.<br>
                      layout := LayoutMorph newColumn addMorph: box1;
                      addMorph: box2.<br>
                      layout openInWorld.<br>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Thanks for the example!</div>
                <div>I used a 20px border to make it more visible.</div>
                <div><br>
                </div>
                <div><img src="cid:part1.09050701.01060103@cuis.st"
                    alt="image.png" height="246" width="146"><br>
                </div>
                <div><br>
                </div>
                <div>They don't share a border looking at
                  fullBoundsInOwner it looks like they do: one ends at
                  y=100 (100@100) and the next one starts at y=100
                  (0@100).</div>
                <div>Would't this imply that their extent is 101@101 px
                  wide?</div>
                <div><br>
                </div>
                <div>box1 fullBoundsInOwner ======> 0@0 corner:
                  100@100 .<br>
                  box2 fullBoundsInOwner =======>  0@100 corner:
                  100@200 .</div>
              </div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I don't think so.</div>
          <div>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.</div>
          <div>But if you think of the numbers like measurements then
            100 - 0 is 100, not 101.</div>
          <div><br>
          </div>
        </div>
        <span class="gmail_signature_prefix">-- </span><br>
        <div dir="ltr" class="gmail_signature">
          <div dir="ltr">
            <div>
              <div dir="ltr">
                <div>
                  <div dir="ltr">
                    <div dir="ltr">
                      <div><font face="arial, helvetica, sans-serif">R.
                          Mark Volkmann</font></div>
                      <div><span style="font-size: 12.8px;"><font
                            face="arial, helvetica, sans-serif">Object
                            Computing, Inc.</font></span></div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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@0 corner: 100@100` will have
    width = 100 and cover exactly 100 pixels wide. I do not like this
    convention at all.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Note that Point doesn't have a problem. It can be used in code
    adhering to either convention.<br>
    <br>
    Now I think this should be part of the Rectangle class comment.<br>
    <br>
    Hope this helps,<br>
    <pre class="moz-signature" cols="72">-- 
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</pre>
  </body>
</html>