GUI Editor improvements (suggestion, feedback) - parts #1 to 5

As I am slowly further experiencing the GUI Editor, I’m noticing a number of things I find missing and some being really annoying. Don’t get me wrong, the work that has been done so far on the editor is already quite impressive. But it’s a different thing when you enter productivity mode.

Here is a shortlist of my first comments:

  1. As already stated before, the fact that you cannot undo/redo is a big issue when it comes to designing a GUI with the editor.

  2. In the same spirit (and somehow cumulative), changing things that heavily impact the layout (and sometimes accidentally) like ‘adapt’ or ‘clip’ to children without it returning to the original state when removing the instruction is just very annoying and time consuming.

  3. Rulers are missing. It’s good to have guides, but these are just the bounderies of objects. Having the ability to place rulers is in my opinion key to mastering design in an editor format.

  4. The ability to select underlying objects with a key combination (may be ‘alt+click’ or “option-click” or similar) would also be very useful, I believe.

I will likely have more comments as I’m continuying my journey with the editor.
Meanwhile, let me wish you a great day :sunglasses: :smiley:


cc @RaananW and @PatrickRyan

1 Like

Sry to bomb you with my comments but you know how it is ‘once you’re on it…’ :wink:
This morning I was working alongside placing elements such as the grid and nine-patch images and I noticed some disturbing behavior of the canvas on resize.

  1. To make things easier, I have been using just a fixed (non-responsive) layout. It appears that the refreshing of the canvas after resize (of the window) only happens on left click in the scene. Not dramatic but not the best for UX.

  2. Using percentage mode with stated 0px padding, I eventually had my grid not returning to its supposingly original top-left position after resize/refresh.

  3. I had the same issue with images, eventually not keeping with their original display/position on the canvas, although the parameters set in numbers remained unchanged and correct (just a visual bug)

  4. It looks like the nine-patch image eventually does disappear when you change the display mode. I mean it’s correct that it does if it does not match the newly selected display mode but the point is that when you return to the correct parameters, the image does not display anymore. I eventually had to create a new image block, set the correct parameters first and only next change the link to my 9-image to see it again displayed correctly.

That’s it for now. I’m afraid it’s likely that their will be more of my ‘crap’ comments :wink: to come… Until this thing will be just perfect, yes? :grin:

Meanwhile, have a great day :sunglasses:



It’s me (The bugger) back again :wink: with a new serie of crap comments. :grin:

As a side note, I’m having more and more this feeling that this ‘beta’ should have remained an ‘alpha’ version. Partly my bad, since I didn’t have (and didn’t invest) time when the Editor was in alpha. As a result, Yours are just getting all of my comments on the beta (sry for that).

So here goes for #part 3:

  1. EZ enough to understand and fix, part of UX, when pressing ‘ENTER’ upon changing a parameter on a control, ‘ENTER’ does not confirm the change. A key press on ‘TAB’ or clicking elsewhere does it.

  2. When selecting from colors, there’s no option to set it to ‘transparent’. The only way is to enter an HEX(a) value.

  3. More tricky, I have been experiencing BUGS when moving a control from a container to another container. I.E. In the ‘Space Pirate Editor Demo’ from the original link in the doc for the GUI Editor, I have been adding a grid to the top menu ‘rectangle’ container. Next, I wanted to move the ‘CharacterClass’ TB to my new grid. As a result, I got a persistant visual box showing the guides/bounderies of my textBlock outside the canvas (while my text and control was and was shown in due place). See SS below. Actually, I experienced this with other controls. It seems like moving a control from a container to another is an operation the editor currently dislikes. I don’t know how to state this differently as I have been unable to figure the translation (why the control visually shows where it is after re-parenting).

  4. In the same spirit, I had a hard time modifying moved/re-parented TB controls; trying to change from pixel values to percentage values after re-parenting. Eventually, I was simply unable to enter percentage values on these ‘moved controls’ (the mode was always returning to pixels upon confirmation of the new value).

4a) Whilst playing with this changing mode of pixels vs percentage, I also noticed that you need to first click on the mode (pixel or percentage) BEFORE entering the value, which is kind of understandable for me moving from the code version but then VISUALLY DISTURBING in the editor because the PX/% is shown to the right (after the value entry). So, I believe, in terms of UX and best understanding, it would be may be better to have this selection of pixels vs percentage first and next, enter the value. My opinion only here.

  1. Last of this serie of comments is more a ‘nice to have’ than a ‘must have’. If I select a container or control in the hierarchy and next add an element, I would expect this element (control or container) to be added either below or above my selection. Currently, adding a new element adds it always on top of all.

That’s all for the moment but rest assured I will be back with this :grinning: :wink:

Meanwhile, enjoy your day :parasol_on_ground: :sunglasses:

1 Like

Gonna drop some of my previous GUI Editor threads here to help collect them:

GUI Editor: export JS module with control accessors - Feature requests - Babylon.js (

[GUI] Need onControlAddedObservable and style inheritance - Feature requests - Babylon.js (

GUI - parseFromSnippetAsync XHR request appears to bypass browser cache - Bugs - Babylon.js (

1 Like

Hello again,
Going a bit further with the Editor, I am continuing to experience some frustrating behavior for UX.

Today on the menu:

  1. Parenting a grid to a stackpanel either horizontal or vertical applies warning changes and converts values to pixels with no way to return to percentage mode. It is a warning, yes? You can disregard it with code and eventually get the result you want. It doesn’t seem like you can do that with the editor.

  2. Saving the file makes the scene return to the default view and also unfolds everything from the hierarchy. Not the best when you are working on a complete GUI.

  3. I noticed that you can load any versioning link that does not yet exist. It will load the latest version but keep with the link you entered.
    In the PG however, loading a version file that does not exist will generate a blank GUI. Not the best for consistency. It would be better if when attempting to load a version that does not exist, the Editor would at least throw a warning stating that this file versioning does not exist (and eventually next load the latest version).

That’s all for just now. Though, there will be more to come… :grinning:
Thanks and have a great day :sunglasses:


Back for another session and a new serie of comments to possibly further improve the UI/UX:

  1. What about a search field to identify an element in the tree/hierarchy (and to find all elements of the same name in the hierarchy)? I believe this would be a good ‘nice to have’

  2. What about the possibility to select all elements in the tree and next use a shortcut or click on icon to either fold or unfold all? This is also related to the fact that when you save your progress, everything gets unfolded (and on a complex GUI it is a real pain to fold everything one by one or scroll down to your container or control). I lost a lot of time just doing this operation on every save.

  3. I am having a huge issue with some limitations regarding percentage VS pixels mode (already exposed in a previous comment above). I think this limitation should simply be removed. Not to mention that it is also working eratically (you can keep with the percentage mode if you use the guides of the control/container, while when entering a value, the mode swaps automagically.

3a) In addition to this, I noticed that I cannot create a stackpanel with no height (or no width). I also cannot ‘hack’ my editor GUI with code, resetting my stackpanel to use ‘no height’ or ‘no width’. Adapt height to children does not solve the issue where (with code), I regularly use this trick to have my root container/stackpanel dynamically resize from the size of all children. This does not work with the Editor (or at least I didn’t find how).

That’s all for just now but I’m sure there will be more to come :wink:
Meanwhile, have a great day :sunglasses:

@PatrickRyan more search field talk :rofl: I was thinking this would be a “nice to have” on the Inspector too :stuck_out_tongue: