I believe that by now after about over 60 hours of use of the Editor, I must be entitled to make this comment:
I mentionned before that I was having an issue with this restriction of using percentage mode where it would simply generate a warning when done with code. I mentionned before that this restriction was also working eratically. I can now confirm that not only does it work eratically but it also lets you enter and accounts the value and mode when typed, yet not if you click on the pixel/percentage button.
I would like to urge you again to consider removing this restriction to simplify and also reflect what can be achieved through code.
Thanks for considering the above and have a great day
Hey there! Just to refresh my memory, is this the restriction when using a StackPanel? Or something else?
Thanks for your reply and constant monitoring. Much appreciated
It actually applies to all elements (containers and controls) when inside a parent of I believe stackpanel.
Not sure if other containers also have this restriction. If I find out I’ll let you know. I didn’t create a use case for this. I’m delivering on the fly while working on the project.
I’d say for now, let’s just focus on the stackpanel and all its children.
As I’m continuing my journey with the editor, I found more reasons to may be remove this restriction/resolve. Let me share about my findings:
It appeared to me that when entering in numbers (== overiding) a value in percentage (i.e. for a textBlock inside a grid container), the save from the Editor takes a lot more time and loading the GUI in the PG/scene also takes a lot more time. Is it so that there would be some sort of resolve going on in the background?
Another reason why this thing is may be not the best in terms of UX is that you cannot always instantly understand why a value could eventually not be entered as percentage. Although knowing the code and components, it took me a while to understand why two textBlocks that looked the same would let me have one enter the value in percentage and the other not… until I realized one of my copied textBlock had a ‘resizeToFit’ set to true. So, between the restrictions we either know or don’t know about for a single component, adding on top this resolve for what should be a simple warning, again I believe, does not help.
Thanks again for considering and have a great day
Hey there! I had some time to think about this, and I think there’s an extra additional improvement that can be done along with removing the restriction on the Editor.
The reason for the code warning/editor restriction on the StackPanel children units is because the StackPanel’s height can be adapted to be just the children’s total height. So the StackPanel needs its children to determine its height, but a child with percentage units needs its parent to determine its own height… which creates a circular dependency. But if
adaptHeightToChildren is not true, and we set a height for the StackPanel (like 100px or even 70%), we don’t need to try to determine this height, it was already given to us. So we could remove the warning in this case, and keep it only in the case that the StackPanel has
adaptHeightToChildren true AND it has a descendant with height in percentage. @RaananW do you think this is reasonable?
Of course, even in the case where we keep the code warning, we should improve the GUI Editor to not try to auto-convert it to pixels, and just display some kind of indication that the value has a different behavior. I think we could add a yellow border to the input with a tooltip or text warning. @PatrickRyan what do you think?
Yes. However, there is still this issue where it’s currently not possible to set NO HEIGHT (or width) to the Stackpanel. This prevents from automagically rescaling the stackpanel from the total height (or width) of its children and is currently a big downside vs the code version.
Can’t agree more. The doc already explains this behavior and the console throws a warning. This shouldn’t result in a restriction, if you ask me.
That would be fine by me (again, my opinion only).
Meanwhile, have a great day and thanks for continuously looking at how to improve our user xp.
Yes! I do
This needs to be well documented, and the warning needs to be adjusted, but I don’t see why we couldn’t do it if the height is fixed and not %-based
We could research if this can be enabled. If all children have a fixed height, then there is no reason to explicitly set the height and it can be automatically assigned. We don’t have the concept of
height: auto , so this might take a little while till we actually support that.
May be I didn’t express this correctly. It totally works with code. May be I should have said “No specified height”. Here’s a PG demonstrating this. When I do not specify any height for the panel, at first the panel is not visible (has a height of zero or no height). By adding chidren to this panel with no specified height, the panel automagically extends to the height and the total height of the children.
When I tried doing this with the editor, I couldn’t. Because the editor sets by default a specified height of 0px that must be passed on, I believe. Once this is done, there’s no way back. I tried with code correcting this by specifying ‘height = null’ but that indeed didn’t work. Adapt height to children also doesn’t do the job. Initially the stackpanel still keeps with this value of ‘something’.
Here the PG with code. You can try reproduce this from the editor. I wasn’t able to.
Hmm yeah I’m taking a look at the behavior of Stack Panel with children and I feel it’s a bit weird, not setting the height works how I expect: Test stack panel with children | Babylon.js Playground (babylonjs.com), but if we don’t set height AND set adaptHeightToChildren to true, then it only adapts to the height of the first child: Test stack panel with children | Babylon.js Playground (babylonjs.com)
yes, something like that. It has never been a worry with code (once you know the trick). Problem is that you just can’t use this trick from the editor.
@RaananW what do you think should be the behavior in this case?
That sounds like a bug, doesn’t it?
The editor should have the flag for the stack panel (“adjust…”). The flag should be removed if a new height was set. Not sure we will make it to editor 1.0, but that would be a nice addition
It sounded weird but I wasn’t sure if it was intended behavior or not :s And then there is the case where it is adapting to the height of the children in the case the height is not set, should we preserve this behavior or not? In the case of other containers, it seems that not setting height is equivalent to “100%” height, but in the StackPanel case it adapts to the children’s height: Babylon.js Playground (babylonjs.com)
Yes, that’s precisely the one I’d really like to keep. It allows for creating dynamic panels. Very helpful for things like i.e. a dropdown menu, an enhanced chatbox or any container inside a scrollviewer with dynamic content.
Edit: Just want to add to this that it works (with code) for both height or width. And (in my opinion) should stay this way. Thanks,
@mawa just opened a PR to make the StackPanel adapt the height correctly also if adaptHeightToChildren was set, no matter if it also has a height: Take into account adaptWidth/HeightToChildren in the StackPanel by carolhmj · Pull Request #13144 · BabylonJS/Babylon.js (github.com) I think this will make working on the editor easier as you won’t need to worry about the height value
Thanks a million. Be sure I will be testing this very shortly. I’ll let you know if anything.
Have an amazing day