<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,<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><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><div><br/></div><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><div><br/></div><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><div><br/></div><div>Cheers,</div><div>Bernhard</div><div><br/></div><div>[1] <a href="https://lists.cuis.st/mailman/archives/cuis-dev/2024-May/008772.html">https://lists.cuis.st/mailman/archives/cuis-dev/2024-May/008772.html</a></div><div>[2] <a href="https://lists.cuis.st/mailman/archives/cuis-dev/2024-June/009021.html">https://lists.cuis.st/mailman/archives/cuis-dev/2024-June/009021.html</a></div><div>[3] <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model#margins_padding_and_borders">https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model#margins_padding_and_borders</a></div><div><div><br/><blockquote type="cite"><div>Am 21.08.2024 um 18:03 schrieb Juan Vuletich via Cuis-dev <cuis-dev@lists.cuis.st>:</div><br class="Apple-interchange-newline"/><div><div>Hi Folks,<br/><br/>On 8/14/2024 5:59 PM, ken.dickey--- via Cuis-dev wrote:<br/><blockquote type="cite">On 2024-08-13 17:01, Mark Volkmann via Cuis-dev wrote:<br/><br/><blockquote type="cite">On Tue, Aug 13, 2024 at 9:18 AM <ken.dickey@whidbey.com> wrote:<br/><br/><blockquote type="cite">On 2024-08-12 17:01, Mark Volkmann via Cuis-dev wrote:<br/><br/><blockquote type="cite">I seem to keep running into situations where I want separation in a<br/>LayoutMorph to only be added between the submorphs and not before the<br/>first and after the last. I see that I can achieve that by modifying<br/>the LayoutMorph method layoutSubmorphsHorizontallyIn:. But I don't<br/>always want that behavior. I'd like that to be configurable. Is there<br/>already a way to do this that I'm missing?<br/></blockquote></blockquote></blockquote><br/><blockquote type="cite">No.<br/></blockquote><br/><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'd rather not have to insert spacer morphs, especially if there<br/>are a large number of submorphs.<br/>I attached my solution which is to create a subclass of LayoutMorph<br/>that adds a boolean instance variable "trim".<br/>When that is true, it avoids adding separation before the first and<br/>after the last submorph.<br/>This works for my use cases.<br/>It would be great if this was added to LayoutMorph. It wouldn't<br/>affect its current behavior.<br/></blockquote></blockquote></blockquote><br/>Mark, thanks much for contributing.<br/><br/>Two things:<br/> [A] I prefer #useEdgeSpace to #trim as 'trim' seems too generic a<br/>term to me. ['shrinkWrap' might work as well].<br/> [B] Due to edge cases, the math is a bit difficult to get right.<br/><br/>Please check the code and try `Layout2Morph example1` in the attached.<br/><br/>I am still testing, but think this may be close to what you want.<br/><br/>Thanks again for this!<br/>-KenD<br/></blockquote><br/>Thank you very much Mark and Ken for working on this!<br/><br/>I've just integrated a slightly later version of this code with your<br/>latest work. It works nicely.<br/><br/>Thanks!<br/><br/>--<br/>Juan Vuletich<br/>cuis.st<br/>github.com/jvuletich<br/>researchgate.net/profile/Juan-Vuletich<br/>independent.academia.edu/JuanVuletich<br/>patents.justia.com/inventor/juan-manuel-vuletich<br/>linkedin.com/in/juan-vuletich-75611b3<br/>twitter.com/JuanVuletich<br/><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>