Hello,
Working with the GUI, I have some issues with the Input Text Area :
-
Setting width to 100% :
When width is 100% the Input Text Area Shrink to fit text : Playground while it’s fine for 99% for example (switch the comments of lines 17 & 18)
Even weirder : if you let both lines (setting to 99% and THEN to 100%) here it works, and is the only way to achieve a 100% width
-
Using autoStretchHeight=true :
Here when using the autoStretchHeight, it expands until a point where it will never scroll, ending up with last lines on top of each other, and black : Playground (Add some lines until it stops expanding, and try to type some text)
If you comment lines 19&20 (no auto stretch) then it’s fine, the text scrolls up while you type, and you can move across lines with arrows
-
(Feature requests)
- Select all is missing with
CTRL+A while it’s very commonly used when you just want to erase or replace the content
- Adding line with
Enter key is not binded on NumPad Enter
++
Tricotou
@RaananW since I see you were assigned this topic, I’m putting here some new feature request about the GUI, if you don’t mind :
height and width of controls : as far as I know only percentage of parent and pixels are available. Example :
rect.height = "300px";
or
rect.height = "30%";
It would be very handy to add the vh and vw of HTML5 (I.E. percentage regarding global width and height of the dom, or the main canvas in our case) for both controls sizes, but as well fontsize. In the current state of the GUI, I think it’s quite hard to have it automatically sized to fit any screen size. In my recent BJS Repo Viewer project I had to code a custom equivalent of vh/vw in order to have a consistent result in both full HD & 4K res.- Scrollbar size : I think it’s quite disturbing that the vertical size is always the same (about 45% of total height) while it should be a percentage which matches the ratio
displayed/total (which uses to be the case for all scrollbars in others GUIs). For example :
Displaying 4 users among 100, the size of the scroll bar should be only 4% of the total.
At the opposite, here :
Displaying 7 users among 11, the scrollbar should be about 63%.
What do you think ? 
++
Tricotou
1 Like
Awesome!
I’ll add those to the backlog, these are great suggestions. And will look into the issue above tomorrow.
1 Like
Hello @RaananW
Following my update on the Babylon JS Repository Viewer topic, I have new materials to share :
I am running a working version (see at the end) of the HTML/CSS vw that I use like so :
control.width = vw(10)+"px";
- Here the
function vw just does a pixel conversion
- At the end the idea would be to be able to do like in CSS :
control.width = "10vw";
Also, there is another issue with the ScrollViewer : The horizontal bar sometimes appear even if there is no horizontal width to scroll (it actually scrolls 1 pixel only). It’s not consistent, depends on the overall size. (Resizing the screen has the horizontal bar randomly triggered, or not)
In therm of issue repro, I can share but I’m not sure it will be the same on another machine since it seems to be size dependent. FYI I’m in FullHD, and on my machine :
- this is not OK (triggers a 1 pixel horizontal scroll)
- this is OK (no horizontal scroll)
In the working version I have added :
subContainer.width = 0.99;
In order to force a smaller size of the inner container, but it’s not very neat…
Having a look at the API I see that there is the forceHorizontalBar param, but it seems it’s only to force it visible with true (false doesn’t hide, but lets it auto). Could be nice to be able to force it false;
++
Tricotou
Hello @RaananW I was thinking : It would make sense to have vw and vh refering to width and height of the canvas (and not the window like in HTLM/CSS) since the canvas can be embedded in a window, and is not necessary full screen. And by the way, I think that the “v” of “vw” and “vh” stands for “viewport”, so still it makes sense 
This might be confusing for people embedding 3D content in a window. If we maintain compatibility with HTML, VH and VW should be relative to the entire window size.
Your point makes sense as well… I let you decide 
Found the time to go over these issues - A few GUI fixes by RaananW · Pull Request #15213 · BabylonJS/Babylon.js (github.com)
You can check it with the snapshots once build is done.
- Fixed setting width 100%
- Fixed scroll with auto height stretch,
- numeric enter is working
Select all is working well (let me know if it doesn’t work for you, i want to understand why)
1 Like
NICE ! Thanks for the fix @Raanan. Just tested on the snapshot the width, the scroll and the numeric enter 
On my side it’s still not working (I can select all with the mouse, but CTRL+A only prints "a")
1 Like
Do you press ctrl a while focused in the text area?
Very nice, it now works on my side Well played
By the way, a nice feature to add to the CI/CD bjsplat would be to read the first description and eventually (if exists) extract the playground ID. That way, you would open the PR with description + Playground exposing the problem.
Then the first bjsplat snapshot message (providing some test links) would edit them so that you just need to click the snapshot link merged with your playground id
(Otherwise, except if I’m missing something, I need to :
- Copy the platform snapshot link
- Copy my playground test link
- Manually merge them together
etc…)
There is a time saver opportunity here 
1 Like
