Bug in TableLayout for #spaceFill + #minExtent?

Hi all,

I think I found a bug in the Morphic TableLayout logic when combining #spaceFill with #minExtent. Please watch the following "minimum failing example":

m := Morph new.
m height: 100.
m changeTableLayout.
m addMorph: (Morph new
    color: Color red;
    vResizing: #spaceFill).
m addMorph: (Morph new
    minimumHeight: 40;
    color: Color yellow;
    vResizing: #spaceFill).
m fullBounds.
m submorphs collect: #height.

Expected output: #(50 50).

Actual output: #(69 31).

Here is also a pic for increasing the reach of this message:

Could you please soon confirm to me that this is a bug?

In my opinion, this is quite obvious because "min extent" does not make any indications like "Please do not regard my extent while laying me out". Its very only effect should be, as stated by the name, "don't shrink me smaller than this value".

This bug gets even more important if you consider that #minExtent cannot only be hard-coded via #minimumExtent but also be computed from a nested table layout that consists of rigid morphs. This way, I became aware of that behavior at all.

I already found the origin of the presumable error: TableLayout >> #layoutTopToBottom:in: or #layoutLeftToRight:in: for the other dimension, respectively. But the same behavior also occurs if a #wrapDirection is specified and we don't get into the "fast line" as described #layout:in:. So I wonder whether this might be a conscious design decision rather than a problem by design. Is it possible at all to reach the desired behavior in linear time? I need to check this, but before doing so, your confirmation or objection would be greatly appreciated.

Best,

Christoph

In case you agree to call this a bug, I'm attaching a test method to detect the issue.

Am 10.09.2020 18:44:57 schrieb Thiede, Christoph <[hidden email]>:

In case you agree to call this a bug, I'm attaching a test method to detect the issue.

---

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Donnerstag, 10. September 2020 18:33:19
An: Squeak Dev
Betreff: [squeak-dev] Bug in TableLayout for #spaceFill + #minExtent?

 

Hi all,

I think I found a bug in the Morphic TableLayout logic when combining #spaceFill with #minExtent. Please watch the following "minimum failing example":

m := Morph new.
m height: 100.
m changeTableLayout.
m addMorph: (Morph new
    color: Color red;
    vResizing: #spaceFill).
m addMorph: (Morph new
    minimumHeight: 40;
    color: Color yellow;
    vResizing: #spaceFill).
m fullBounds.
m submorphs collect: #height.

Expected output: #(50 50).

Actual output: #(69 31).

Here is also a pic for increasing the reach of this message:

Could you please soon confirm to me that this is a bug?

In my opinion, this is quite obvious because "min extent" does not make any indications like "Please do not regard my extent while laying me out". Its very only effect should be, as stated by the name, "don't shrink me smaller than this value".

This bug gets even more important if you consider that #minExtent cannot only be hard-coded via #minimumExtent but also be computed from a nested table layout that consists of rigid morphs. This way, I became aware of that behavior at all.

I already found the origin of the presumable error: TableLayout >> #layoutTopToBottom:in: or #layoutLeftToRight:in: for the other dimension, respectively. But the same behavior also occurs if a #wrapDirection is specified and we don't get into the "fast line" as described #layout:in:. So I wonder whether this might be a conscious design decision rather than a problem by design. Is it possible at all to reach the desired behavior in linear time? I need to check this, but before doing so, your confirmation or objection would be greatly appreciated.

Best,

Christoph