Lazarus 4: Changes in ChildSizing in Lazarus 4?

[stem]

Hi,

with Lazarus 3.6 my application looked fine. The controls were aligned
with ChildSizing and crsHomogenousChildResize horizontally and vertically.

With Lazarus 4, the controls are overlapping and I have to switch to
crsHomogenousSpaceResize. After that, the controls are now not overlapping
any more but there is too much unnecessary space around the controls.

Does anybody have further experience with that?

Thanx.

stem

[wp]

Prepare a small demo showing this.

[stem]

Another example is in the attachment: The caption of LabelTitle is "Title:",
autosize is true and width is 8 (?) as is shown in the form designer.

But with this example, during runtime everything is displayed fine.

[Martin_fr]

There was some change to the code when crsSameSize was added.

IIRC also some bugs, like
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/689ef2119fc3ddd53347006d59ba0470b1165850
where horizontal and vertical values were mixed up.

And https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/22881f66dba0d418be39152603030d09c6334790 and
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/1f35f2f89b1dcc54651a944f0215f9a084de0121
 mentions "fixed constraint handling". But, don't recall the exact issue that did get fixed.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/a3a1abb9a657afb11ef8c720695c48c946ba110 "fixed" or enabled some autosizing.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/560c6818f93093b0a7de957034c236ea1f5a850c fixed  https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/24986




So it could be a side effect of some bug fix (your code/design used the behaviour of the bug and relied on it).
Or it could be an accidental change.

But without knowing more about your case it wont be possible to tell.

[Martin_fr]

We need an actual sample project that we can open ourself on our own computer, and then get the changed behaviour.

I do have both 3.8 and 4.0 installed. So I can test, and then try to find out why.



As for the "autosize in designer" => This may (or may not) be a separate issue.
I do recall a while back that I had some autosize did not trigger in designer issues. But those were with controls/forms that had no childsizing at all.
In my case, as soon as I tried to resize (with the mouse, moving the "square dot" selector in the designer) the control by a few pixels, it would autosize.
Unfortunately I was never able to reproduce this, so this is still an open issue.
Of course, yours may be something different than what I had...

[stem]

I'm having this issues in a very complex project but I'm trying to generate a minimal example.

[stem]

You can find a minimal example in the attachment.

Open it with different versions of Lazarus, change the size of the window constantly and see the different behavior.

edit: I've added some screenshots

[Martin_fr]

Some initial feedback.

It seems that setting the Constrainsts.MaxWidth/Height for any single item in the panel (when the panel does childsizing), will limit the width of the entire column. => that is all other controls in that colum (row for height) will be restraint too.

So the constraints that some of your controls have will cause this.

I have to check why it ended up like this. And see if/how to fix it.


It seems there were some intentional changes, that may (or may not be related).

- When setting the MinWidth of a control then that column would become wider => that is expected and ok.
- In that case, the for homogeneous-child-resize the other columns shrink accordigly.

- When (in 3.8 ) setting all controls in a column to MaxWidth = <small>, then that column shrinks. => also ok
- However, the column only shrinks by a small part of the new available space. The other columns do not take up the full available space => That is definitely wrong.



E.g in a panel.width=300, with a 3x3 grid of buttons:
- if all middle buttons have Constraints.MaxWidth= 20
- then the outer 2 columns should take the remaining 280 (or 140 each).
- But they did not.

I haven't checked any more details yet... My guess would be that the "MinWidth" logic was incorrectly applied to MaxWidth.
- The minWidth of the column is the "Biggest MinWidth of all controls in that column" => ensuring that the widest control can still fit.
- Apparently now the MaxWidth of the column is the "Smallest (non zero) MaxWidth of all controls in that column".


Not sure why space-resize is not affected => it still ends up with a column size.

[Martin_fr]

I think I recall what lead to the new "MaxWidth" (and Height) behaviour.

If a control in a column is forced to 200 pixel width (by Contstraint.MinWidth) then all other controls in that column will also grow to that width. (as they fill the column / unless they have constraints of their own). Well at least ccaFill.

One possible expectation is the that, if a control in a column is limited to 20 pixel width (by Constraints.MaxWidth), then it should also fill the column entirely. That means the other controls in that column have to shrink accordingly.

However, even if that logic is followed, it does not currently actually check for ccaFill. And for e.g. ccaLeftTop this does not apply.

[Martin_fr]

I would propose to keep the new MaxWidth, if - and only if - CellAllign is ccaFill.

The old behaviour basically was that the control (being constraint) would not fill the cell, and behave like ccaLeftTop.

For you app that should mean, after the fix you will have to change BorderSpacing.CellAlign to ccaLeftTop for any control with a max constraints.


I hope we can agree on that the old (3.n) behaviour had at least one issue that should be considered a bug.

- When all controls in a column where constraints, the homogeneous-child-resize did not resize the other columns to fill up the now empty space. Instead a gap was left between the columns.

If that is fixed, then it needs to be defined what should happen when only one row in a column has a MaxWidth. In the old behaviour that would
- violate ccaFill
- be inconsistent with MinWidth

Though consistency with MinWidth will never be 100% as MinWidth does not depend on CellAlign.

Since (if) other controls in the row do not have constraints, then they are actually free to resize. So ccaFill can be fulfilled.

Of course if there are conflicting multiple Min/Max constraints then it still has to break CellAlign.


This offers the possibility to limit the width of a column based on data in some rows. The user code does not have to copy the constraint to all controls.

For old apps the original behaviour can be restored (once a fix is applied) relatively easy by setting ccaLeftTop. (or other)

Setting ccaLeftTop for such a control should also be ok in 3.8 / Though I have not tested it.


This would be added to the list of compatibility changes on the release notes.


If you think there should be a different fix, then please feel free to explain. Thanks.

[stem]

I would agree with any fix so that I can keep using Lazarus 4. 

[Martin_fr]

Turns out to be a bit more complex.

It will work for your form. But I am still working on the patch (some unexpected side effects...)
Your form is basically "Panel1"

Since I am still working on the patch, I would welcome any feedback.
If you think any of the below is flawed, or may cause future problems, or you have a better idea, or just have a question, ....

I'd rather know now, than later.

But for general purpose. See the image.
- Using crsHomogenousChildResize
- Lazarus 4.99 with patch to check for ccaLeftTop

* 3 Panels. The 2nd and 3rd column are not constraint in any of them.
- Panel1: First column, only top button has MaxWidth.
- Panel2: First column, only top button has MaxWidth and ALL buttons are ccaLeftTop
- Panel3: First column, ALL buttons have MaxWidth and ccaLeftTop

Except for those mentioned all other child controls are ccaFill.

Doing the same in Lazarus 3.n:
 - Any MaxWidth constrained child control acts as if it was ccaLeftTop.
 - Therefore ccaLeftTop is not needed for any of the constrained children. The results were the same for all (constrained) buttons = ccaFill.
 - The 2 non-constrained buttons on Panel2 will follow the difference between ccaFill and ccaLeftTop (and follow the same way as in 4.0)


In none of those examples is the overall width of the first column limited to the constrains at all.
The width of column1 follows the following rule: homogeneous resize based on the biggest preferred width by any contained child control. (*1).
- Panel1:  The widest button is either of the 2 non constrained.
- Panel2:  The widest button is either of the 2 non constrained.
    The difference is, that the buttons are ccaLeftTop. So while the column reserves the same space as in Panel1, the buttons are not scaled to the column width, they just sit in the corner.
- Panel3:  The widest button is any of them, and its width is the constrained MaxWidth.
   The column is the scaled based on the percentage the MaxWidth had compared to the other columns.

If on any Panel for any single one of the MaxWidth children the ccaLeftTop changes to ccaFill, then the entire first column will be constrained to that MaxWidth.
 
So far so good.

If we had different MaxWidth, then this allows us to apply the smallest MaxWidth to the entire column. This will happen if all controls that should have their MaxWidth considered for the column are set to ccaFill.
A control with a bigger MaxWidth can shrink to the width given by the other controls smaller MaxWidth. And then they all fill their cell.

But, if we have different MaxWidth, and we want the largest MaxWidth to apply, then the other children (children with smaller MaxWidth) must be ccaLeftTop.
And if MaxWidth are dynamically applied, then those settings must be dynamically adjusted.

Well, I guess its fair game...


(*1)

The "biggest preferred width" is limited by MaxWidth. That is, if a MaxWidth constrained button had a preferred width of e.g 500 (and that was the biggest in the column), then the 500 would not be used, if that button had a MaxWidth of e.g. 100.
(The 100 might be used, if it was the "biggest preferred width" among all the buttons in the column)

[Martin_fr]

Btw, I guess there is (at some point / maybe later) room for another feature...

On your example, the first column has labels. Those labels are fixed size. The layout does not benefit if that first column grows its width.

Of course with the new MaxWidth + ccaFill you can constrain that first column to the width of the widest label.
But, that would require you to find that label yourself, and copy its width to the MaxWidth (and keep that updated if ever it changed).

What would be cool, was if the first (or any) column could be excluded from growth, and fit its content exactly...

[stem]

Hi Martin,

thank you for your work. Is there a way to test your current patch?

stem

[Martin_fr]

It does get some column sizes wrong.

Code: Diff  [Select][+][-]

1.  lcl/include/wincontrol.inc | 8 ++++++--
2.  1 file changed, 6 insertions(+), 2 deletions(-)
3.  
4. diff --git a/lcl/include/wincontrol.inc b/lcl/include/wincontrol.inc
5. index 935d5f452e..e8a98a82da 100644
6. --- a/lcl/include/wincontrol.inc
7. +++ b/lcl/include/wincontrol.inc
8. @@ -1399,8 +1399,12 @@ procedure TAutoSizeBox.SetControl(AControl: TControl);
9.    Control:=AControl;
10.    MinimumSize[asboHorizontal]:=Control.Constraints.EffectiveMinWidth;
11.    MinimumSize[asboVertical]:=Control.Constraints.EffectiveMinHeight;
12. -  MaximumSize[asboHorizontal]:=Control.Constraints.EffectiveMaxWidth;
13. -  MaximumSize[asboVertical]:=Control.Constraints.EffectiveMaxHeight;
14. +  MaximumSize[asboHorizontal]:=0;
15. +  MaximumSize[asboVertical]  :=0;
16. +  if Control.BorderSpacing.CellAlignHorizontal = ccaFill then
17. +    MaximumSize[asboHorizontal]:=Control.Constraints.EffectiveMaxWidth;
18. +  if Control.BorderSpacing.CellAlignVertical = ccaFill then
19. +    MaximumSize[asboVertical]:=Control.Constraints.EffectiveMaxHeight;
20.    Control.GetPreferredSize(PreferredSize[asboHorizontal],
21.                             PreferredSize[asboVertical],
22.                             true, // without constraints
23.