<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"/></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Ken,<div><br/></div><div>I agree that the margin functionality could be introduced in a separate step.</div><div><br/></div><div>Here is an example where a margin is useful, though:</div><div><img alt="PastedGraphic-1.png" src="cid:E0F45D19-C124-4BA1-9FBA-BA48FBB3A539"/></div><div><br/></div><div>The container has a gap of 30px and a padding of 0px. Only red has a margin of 8px in addition.</div><div><br/></div><div>You can play around with the values here: <a href="https://codepen.io/bpieber/pen/PoraLjm">https://codepen.io/bpieber/pen/PoraLjm</a></div><div><br/></div><div>Note that only four morphs are needed, neither spacers nor wrappers.</div><div><br/></div><div>Maybe margin could be emulated by a wrapper with transparent border color.</div><div><br/></div><div>Cheers,</div><div>Bernhard</div><div><br id="lineBreakAtBeginningOfMessage"/><div><br/><blockquote type="cite"><div>Am 26.08.2024 um 21:27 schrieb ken.dickey--- via Cuis-dev <cuis-dev@lists.cuis.st>:</div><br class="Apple-interchange-newline"/><div><div>I also would like LayoutMorph's to retain #spacing and not add the<br/>complexity of individual #margins, negative margins et al.<br/><br/>What use cases in Cuis would offset the added complexity of #margin<br/>calculation?<br/><br/>I like #padding added to #BoxedMorph.<br/><br/>I suspect the #minimumExtent and #morphExtent would continue to refer to<br/>the exterior edge of a Morph. Proportional layout also w.r.t. exterior<br/>edges. #morphPosition as the upper-left point of the border.<br/><br/>Perhaps a new #contentExtent synthesized from #morphExtent less 2 *<br/>(#borderWidth + #padding)?<br/><br/>$0.02,<br/>-KenD<br/><br/><blockquote type="cite">On Mon, Aug 26, 2024 at 9:45 AM Juan Vuletich <juan@cuis.st> wrote:<br/></blockquote>..<br/><blockquote type="cite">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<br/>needs the boundary between current Border and the "inside" of the morph<br/>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<br/>part of its LayoutSpec. It is not considered part of the morph at all.<br/>It is only used by the containing LayoutMorph. This design is<br/>consistent with [1], that states: "Note: The margin property also<br/>affects the total space that the box will take up on the page, but the<br/>margin is not included in the actual size of the box. The box's total<br/>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<br/>LayoutSpec. It is to be used in place of "separation" or "spacing".<br/>- Padding is moved up to BorderedMorph as you suggest. LayoutMorphs<br/>would inherit it. This means that any BorderedMorph could have a<br/>non-zero padding of their contents<br/>- LayoutMorph would no longer have 'separation' and 'margin', neither<br/>'useEdgeSpace' nor a specific 'padding'.<br/><br/>I think this would cover all the suggested use cases.<br/><br/>Opinions?<br/></blockquote><br/>On 2024-08-26 08:16, Mark Volkmann via Cuis-dev wrote:<br/><br/>I like the proposal to add padding to BoxedMorph.<br/><br/>Do I understand correctly that there is a desire to remove separation<br/>from LayoutMorph? I don't think I like that. I think LayoutMorph needs<br/>an easy way to specify the gap that should be present between each<br/>submorph. But I think the gap should not be applied before the first<br/>submorph and after the last submorph. The new padding in BoxedMorph can<br/>handle that. Adding a margin to each submorph can achieve the same<br/>result, but that seems more tedious to apply.<br/><br/>Object Computing, Inc.<br/>--<br/>Cuis-dev mailing list<br/>Cuis-dev@lists.cuis.st<br/>https://lists.cuis.st/mailman/listinfo/cuis-dev<br/></div></div></blockquote></div><br/></div></body></html>