<div dir="ltr"><div dir="ltr">On Mon, Aug 26, 2024 at 9:45 AM Juan Vuletich <<a href="mailto:juan@cuis.st">juan@cuis.st</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
    
    
  
  <div bgcolor="#ffffff">
    Hi Bernhard,<br>
    <br>
    On 8/25/2024 4:10 PM, Bernhard Pieber via Cuis-dev wrote:
    <blockquote type="cite">
      
      Hi,
      <div><br>
      </div>
      <div>Sorry for the late reply. I just read this thread after a
        holiday away from the keyboard.</div>
      <div><br>
      </div>
      <div>It's great that that functionality got integrated. I had the
        same need and proposed a change set in May, see the email thread
        "LayoutMorph separate padding and spacing" [1] and my answer in
        the thread "morphs padding and margin" [2].</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    Apologies. I forgot about your contribution.<br>
    <br>
    <blockquote type="cite">
      <div>However, instead of an additional boolean instance variable
        (useEdgeSpace) I chose to split separation into padding (inner
        distance to the borders) and spacing (distance between
        elements). I chose the name padding because that's how it's
        called in the CSS box model [3].</div>
    </blockquote>
    <br>
    This is good. There's no reason to do it differently if what is well
    known is perfectly fine, and doing it in our unique way only annoys
    people without bringing an improvement.<br>
    <br>
    <blockquote type="cite">
      <div>I did keep the instance variable separation in the first
        step, as it is currently used in UI-Panel and UI-Click-Select in
        Cuis-Smalltalk-UI. However, I prepared updates for those
        packages after which the instance variable separation should be
        deleted.</div>
    </blockquote>
    <br>
    Please post your code for these packages. (see my suggestion below)<br>
    <br>
    <blockquote type="cite">
      <div>In a third step the instance variable padding could be moved
        to the superclass BoxedMorph and be supplemented by the property
        margin (outer distance to the borders), which is also part of
        the CSS box model [3] and widely used in web design.</div>
      <div><br>
      </div>
      <div>I would ike this design because LayoutMorph would become
        simpler again, BoxedMorph would become more flexible and at the
        same time easier to understand for people with knowledge of CSS.
        What do you think?</div>
    </blockquote>
    <br>
    I think this should be the first step, actually, as it impacts on
    the resulting design for LayoutMorph.<br>
    <br>
    This is my suggestion:<br>
    - BoxedMorph would have 2 "Borders": Border and Padding<br>
    - Padding is drawn the same as background, i.e. using the morph
    'color'<br>
    - Padding behaves as an inner part of the current Border. Any code
    that needs the boundary between current Border and the "inside" of
    the morph would now get the boundary between Padding and the area
    inside it.<br>
    - Margin is only a property that a morph can be queried about, and
    is part of its LayoutSpec. It is not considered part of the morph at
    all. It is only used by the containing LayoutMorph. This design is
    consistent with [1], that states: "Note: The margin property also
    affects the total space that the box will take up on the page, but
    the margin is not included in the actual size of the box. The box's
    total width and height stops at the border."<br>
    <br>
    So, Bernhard, the difference with your design would be:<br>
    - Margin is moved from LayoutMorph to the inner morphs, but to their
    LayoutSpec. It is to be used in place of "separation" or "spacing".<br>
    - Padding is moved up to BorderedMorph as you suggest. LayoutMorphs
    would inherit it. This means that any BorderedMorph could have a
    non-zero padding of their contents<br>
    - LayoutMorph would no longer have 'separation' and 'margin',
    neither 'useEdgeSpace' nor a specific 'padding'.<br>
    <br>
    I think this would cover all the suggested use cases.<br>
    <br>
    Opinions?<br></div></blockquote><div><br></div><div>I like the proposal to add padding to BoxedMorph.</div><div><br></div><div>Do I understand correctly that there is a desire to remove separation from LayoutMorph? I don't think I like that. I think LayoutMorph needs an easy way to specify the gap that should be present between each submorph. But I think the gap should not be applied before the first submorph and after the last submorph. The new padding in BoxedMorph can handle that. Adding a margin to each submorph can achieve the same result, but that seems more tedious to apply.</div></div><div><br></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>