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
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.
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.
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.
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,
rescaling the stackpanel from the total height (or width) of its children and is currently a big downside vs the code version.
Be sure I will be testing this very shortly. Iāll let you know if anything.