That would be easy to change the computation and to take into account the padding of the children, but that would be a breaking change and maybe it was intended that way…
It looks to me that the paddings are “inside” the control, meaning within the boundary of the width (for the left/right padding) - they don’t increase the width, in which case the current behaviour (not taking into account the children padding in the width computation) is the right one.
I would prefer waiting for @Deltakosh input about this before going further.
From what I can tell, when you set a width + paddingLeft + paddingRight on a control, the width of the control is really “width”, it is not “width+paddingLeft+paddingRight”.
From the GUI doc:
This means that the usableWidth = width - paddingLeft - paddingRight.
Same for usableHeight = height - paddingTop - paddingBottom.
So, when using adaptWidthToChildren, it seems right to me to use width from the children and not width+paddingLeft+paddingRight: width/height define the boundaries of a control.
I have changed the PG to remove the rectangle and directly add the text to the GUI texture. I have also highlighted the text so that we can see what is the bounding rectangle of the text:
If you comment the padding, you will see no change: so, the problem is not that the padding are not factored in the computation when using adaptWidthToChildren = true on the parent container, it is that they are not taken into account in the text control when resizeToFit = true.