[Cuis-dev] Column type layout morph anomaly

[Juan Vuletich]

Hi Folks,

Thanks for identifying and discussing this issue.

On 8/6/2023 5:07 PM, Hilaire Fernandes via Cuis-dev wrote:
> Ah yes indeed your first and last examples in your screenshot are not 
> symmetric.
>
> When I look at the methods, #heightsFor:within: and #widthsFor:within: 
> , they allocate the height and width of each submorphs in a vertical 
> and horizontal layout, these methods are not symmetric, it could 
> explain the different behavior. May be Juan has good reason for that.
>
> Hilaire
>
> Le 06/08/2023 à 10:53, Szabolcs Komáromi a écrit :
>> I suppose the intended behavior of the less than one case is to 
>> occupy only part of the available area. And this is what we see with 
>> the row-proportionalHeight, row-proportionalWidth and 
>> column-proportionalWidth cases. But strangely the 
>> column-proportionalHeight combination deviates and fills up the 
>> entire area. 

Yes. That was the original intent. I thought that proportional numbers 
adding to one or less than one should mean fractions (i.e. percentages) 
of available space, while numbers adding to more than one should mean 
fractions of whatever the sum is. If you rollback #heightsFor:within: to 
the previous version, that is indeed the behavior.

Not a long time ago I got tired of message lists (for example 
'implementors') would use by default too much space for the list, even 
if there are just a couple of long methods (where space is better used 
to show code). So what I did is for #buildMorphicWindow to be able to 
tell #limitLayoutHeight to the method list. After several tries I got 
this working reasonably right.

But the example you posted shows a clear case where I broke existing 
behavior. I just pushed a fix. Instead of scaling proportional elements 
in every case, it will do it only if the original proportions (without 
considering #limitLayoutHeight) add up to 1 or more. So the example you 
tried works as expected.

Again, thanks for identifying the issue, and clearly documenting the 
expected and actual behavior. This makes fixing issues SO MUCH easier! 
Szabolcs, this exercise you do of checking the geometry math by hand is 
invaluable. Having more eyes on the details means less bugs and a better 
system.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich