Bug in TableLayout for #spaceFill + #minExtent?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in TableLayout for #spaceFill + #minExtent?

Christoph Thiede

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



Reply | Threaded
Open this post in threaded view
|

Re: Bug in TableLayout for #spaceFill + #minExtent?

Christoph Thiede

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




TableLayoutTest-testMinimumExtent.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in TableLayout for #spaceFill + #minExtent?

marcel.taeumel
Hi Christoph,

thanks for this report. Overall, the support for minimum extent in Squeak's layouts is rather ... hmpf. For TableLayout, however, it should work.

I will take a look into it.

Best,
Marcel

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