[Cuis-dev] LayoutMorph separation

[Bernhard Pieber]

Hi Juan,

> Am 26.08.2024 um 16:45 schrieb Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st>:
> Apologies. I forgot about your contribution.

No worries! I should have followed up on the proposal earlier myself.

>> 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)

See the attached Cuis-Smalltalk-UI changes.zip. It removes all references to the instance variable separation and all senders of xSeparation and ySeparation, so the instance variable can be deleted. Here is how I found them:

Feature require: 'UI-MetaProperties'.

"Print and browse all methods referencing the instance variable separation or sending #xSeparation or #ySeparation in classes other than LayoutMorph."
| methods |
methods := OrderedCollection new.
LayoutMorph allSubclasses do: [:cls | methods addAll: (cls allAccessesTo: 'separation')].
#(xSeparation ySeparation) do: [:selector |
methods addAll: (Smalltalk allCallsOn: selector)].
methods := methods reject: [:method | method classSymbol = #LayoutMorph].
methods do: [:method | | package |
package := CodePackage packageOfMethod: method ifNone: [].
Transcript cr; show: 'Package: '; show: package packageName; show: ': '.
method printClassAndSelectorOn: Transcript].
Smalltalk
browseMessageListUnsorted: methods
name: 'References to separation, Senders of xSeparation and ySeparation'
autoHighlight: 'separation'.

My change set is a prerequisite for loading the packages.

>> 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.

I like that!

> - 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 your proposal. However, as Mark wrote I also think spacing on the level of LayoutMorph would still be needed. How would you emulate this behavior with only margins in the layouts specs on the level of submorphs?

| row |
row := (LayoutMorph newRow padding: 0; spacing: 10) name: 'padding & spacing'.
row
color: Color white;
addMorph: (BoxedMorph new noBorder; color: Color random; name: 'A')
layoutSpec: (LayoutSpec proportionalWidth: 1 / 3);
addMorph: (BoxedMorph new noBorder; color: Color random; name: 'B')
layoutSpec: (LayoutSpec proportionalWidth: 1 / 3);
addMorph: (BoxedMorph new noBorder; color: Color random; name: 'c')
layoutSpec: (LayoutSpec proportionalWidth: 1 / 3).
row morphPosition: 150 at 130 extent: 400 at 300.
row openInWorld

Actually, instead of spacing we should call it gap, as this is the CSS property name for this behavior [1]. As we currently support only one direction in a LayoutMorph a point instead of a number – as I implemented it – does not make sense.

For even greater flexibility margin, border, and padding could support Rectangles in addition to Numbers and Points.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap

Cheers,
Bernhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240827/d5f521c7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cuis-Smalltalk-UI changes.zip
Type: application/zip
Size: 37166 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240827/d5f521c7/attachment-0001.zip>