[Cuis-dev] Column type layout morph anomaly

[Szabolcs Komáromi]

Yes, when the proportions add up to one or grater than one the behavior seems consistent and I understand it. With my original question I wanted to point out that the less than one case seems inconsistent. It works differently for one possible combination out of the four. (column/row direction and  proportionalHeight/proportionalWidth dynamic sizing) 

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. 

Regards,
Szabolcs

On Sun, Aug 6, 2023, at 00:05, Hilaire Fernandes wrote:
> This looks normal to me. It just mean that if you add *one* morph to a 
> layout morph it will occupy all its space. This is the default behavior. 
> If your added up proportion is greater than 1, I expect it to be 
> normalized to add up to 1. Should be possible to check that in the 
> layout code.
> 
> Hilaire
> 
> Le 05/08/2023 à 22:06, Szabolcs Komáromi a écrit :
> > But the most simple disproof about the proportions should be 1 in 
> > total is the initialize method of LayoutSpec. It will set the 
> > proportional ratios 1.0. So if we have 2 submorphs initialized this 
> > way we will have the combined ratios of 2 in total.  And the submorphs 
> > will have 50% (1/2) of the total area.
> >
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230806/b3a5f291/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 199143 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230806/b3a5f291/attachment-0001.png>