question about proportionalWidth/proportionalHeight sizing difference in horizontal layout

[davidedc]

(same question applies for symmetric case of vertical layout)

Basically:

• if I add morphs as "proportionalWidth" in an horizontal layout, then the elements' width is proportional to each other, such that the morphs fill the row
• if I add morphs as "proportionalHeight" in an horizontal layout, then the elements' height is proportional to the row height (rather than to each other)

it would seem more logical to me that the second case should behave like the first - height of the elements should be calculated in proportion to all the added morphs rather than only to the height of the container

Example:

| pane rect1 rect2 |
pane _ LayoutMorph newRow separation: 5. "1"
pane addMorph: (StringMorph contents: '1').

rect1 := BorderedRectMorph new color: (Color lightOrange);
    layoutSpec: (LayoutSpec  proportionalWidth: 2.0 fixedHeight: 30 minorDirectionPadding: #center).
pane addMorph: rect1.
rect2 := BorderedRectMorph new color: (Color cyan).
pane addMorph: rect2
    layoutSpec: (LayoutSpec  proportionalWidth: 0.5 fixedHeight: 30 minorDirectionPadding: #center).
pane
    color: Color lightGreen;
    openInWorld;
    morphPosition: 320 @ 50;
    morphExtent: 180 @ 100.


pane _ LayoutMorph newRow separation: 5. "2"
pane addMorph: (StringMorph contents: '2').

rect1 := BorderedRectMorph new color: (Color lightOrange).
pane addMorph: rect1 
         layoutSpec: (LayoutSpec  fixedWidth: 20 proportionalHeight: 2.0 minorDirectionPadding: #center).
rect2 := BorderedRectMorph new color: (Color cyan);
    layoutSpec: (LayoutSpec  fixedWidth: 20 proportionalHeight: 0.5 minorDirectionPadding: #center).
pane addMorph: rect2.
pane
    color: Color lightGreen;
    openInWorld;
    morphPosition: 520 @ 50;
    morphExtent: 180 @ 100

See how in the first case the orange morph is 4 times as big as the other (since proportionalWidth is 2 vs 0.5 of the other morph), which in the second example the height is just such that the orange one is just two times as tall as the row. This can be seen as well resizing both layoutMorphs...

Am I missing something?

[davidedc]

Or perhaps there could/should be an option for a row to be "vertically fitting" all the proportional elements according to their relative height proportions, just it is horizontally-fitting all the proportional elements according to the relative horizontal proportions. Is there such a way to do that? (so in the example 2 above, the orange bar would be 4 times as tall as the blue one).

[jvuletich]

Davide, we could modify the behavior to be as you suggest. I even did it to play a bit with it (and haven't included the tweak in the update stream).
For minor direction layout (height in your example), the parameter (2.0 and 0.5 in your example) are taken as fractions of the available space. If a fraction greater than 1 is specified, it is considered 1. I think it is simple, and enough.
For major direction, I scaled everything by the sum of all fractions, but only if that sum is greater than one. This makes it easy to keep adding widgets without needing to tweak the fractions of all the previous ones. But it also allows exact control (by giving fractions that sum to less than 1).
Does this makes sense? Do you still see a reason for changing the minor (vertical) layout?

[davidedc]

Got it. I don't have a practical case. I'm going through the code and I was wondering if having only one unique way of calculating the proportions could be enough, it would seem simpler as opposed to having two, but maybe a matter of taste.

(which brings me to another question - the "adjustHorizontallyByAt" and "adjustVerticallyByAt" seem to be symmetrical methods that could be handled by one same function. Perhaps another case of having "one way of doing both things", perhaps would be simpler? )

[jvuletich]

Well maybe those could be unified. If I remember correctly, when I wrote them I didn't find a trivial way to do it, without a significant performance penalty.

[jvuletich]

Please email https://lists.cuis.st/mailman/listinfo/cuis-dev if you think this deserves further discussion.