[Cuis-dev] LayoutMorph separation

[Mark Volkmann]

On Mon, Aug 26, 2024 at 9:45 AM Juan Vuletich <juan at cuis.st> wrote:

> Hi Bernhard,
>
> On 8/25/2024 4:10 PM, Bernhard Pieber via Cuis-dev wrote:
>
> Hi,
>
> Sorry for the late reply. I just read this thread after a holiday away
> from the keyboard.
>
> 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].
>
>
> Apologies. I forgot about your contribution.
>
> 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].
>
>
> 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.
>
> 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.
>
>
> Please post your code for these packages. (see my suggestion below)
>
> 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.
>
> 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?
>
>
> I think this should be the first step, actually, as it impacts on the
> resulting design for LayoutMorph.
>
> This is my suggestion:
> - BoxedMorph would have 2 "Borders": Border and Padding
> - Padding is drawn the same as background, i.e. using the morph 'color'
> - 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.
> - 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."
>
> So, Bernhard, the difference with your design would be:
> - Margin is moved from LayoutMorph to the inner morphs, but to their
> LayoutSpec. It is to be used in place of "separation" or "spacing".
> - 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
> - LayoutMorph would no longer have 'separation' and 'margin', neither
> 'useEdgeSpace' nor a specific 'padding'.
>
> I think this would cover all the suggested use cases.
>
> Opinions?
>

I like the proposal to add padding to BoxedMorph.

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.

-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240826/d94acc90/attachment.htm>