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

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:


Still on it trying to make the best of the incredible capabilities of the tool, I have a new feature request and a couple of comments:

  1. As a ‘nice to have’, it would be good if transparent colors outside the canvas (on the desk) would also show with the transparent grid texture. Currently they show as if they where opaque (see SS below).

  2. More problematic and possibly a ‘must have’ (and a bug) when parenting or reparenting a control or container to a grid cell, the control or container does not always show. Solution is to assign it to another cell then change the cell again and suddenly it will appear. To debug, I can only encourage you to try it (a screenshot wouldn’t help here). Create a grid and some controls, next try assigning controls to the grid. Eventually create a new row or a new column and move your control to this newly created cell. At some point, you should bounce into this issue that is recuring for me.

  3. As already stated before, there clearly is an issue (a bug) with the display of guides (bounderies) on controls and containers after parenting or reparenting. The guides have this weird tendancy of displaying offset from the control. To reproduce, create a few containers and controls. Next reparent your control to a new container. At some point, you should bounce into this issue. Feel free to use my snippet link in the screenshot below to debug this

That’s all for just now but rest assured that I will likely be back and continue bothering you with it :stuck_out_tongue_winking_eye:
Meanwhile, have a great day :sunglasses:

1 Like

Hi @carolhmj and @PatrickRyan Just wanted to remind yours on this. I just had another experience with the Editor today. Spent nearly 2 hours trying to understand why my textBlock in a multi-layout would not take the isVisible parameter. I was about to give up and post a bug when I suddenly realized that there might be another control with the same name in my multi-layout. And this was it. Now my point is that, in a quite extended layout with dozens of controls and containers, it is really not ez to spot and remember controls with a same name.

The search field here would certainly have saved me a lot of time and troubles. So, I wanted to double check if this is still in discussion/in the pipeline or if I have to forget about it?
Thanks and have a great day :sunglasses:


Yes, search functionality is on the list as part of our shared controls work. It probably best if we have name validation as well so that we add a suffix - like a number - after any control name that is not unique. This would mean substring searching, but that’s likely what we need to do for the greatest flexibility anyway.


Was just thinking the same - better to guarantee control name uniqueness to solve the problem right.

These types of problems have been solved already in the past - WebForms particularly comes to mind here as there are numerous parallels - e.g WebForms implements an algorithm to generate unique control ids based on the controls tree. Wonder if plundering those types of things would save effort?

Hey @mawa,
I’ve read this thread and it looks like you have a lot of good ideas and the good eye for catching things that could be improved.
After all of this I thought that maybe you would like to contribute to GUI Editor? I guess all of this is open sourced. Some of the minor things you’ve mentioned look like perfect tasks to get started.
Just a thought :slight_smile:
Cheers and keep on writing those “crap” comments :wink:

Thanks for your encouraging comment :hugs:. I had the feeling I was already contributing… my way.
Just don’t expect me to write code for the Editor. Fact is, I’m not a true dev - Rather a PM and designer. If you (and I) want clean code and good logic for this, it’s best if I leave this part for somebody else to do :grin: :wink: I hope you are not too much deceived by my answer :face_holding_back_tears: Have a great day :sunglasses:

1 Like

Well, I’m not all too sure anymore. I know I asked for it but after that, I accounted the actual state and turned out to be a potential benefit depending on use case. Unless the suffix does not change the name of control? And then, I guess it will also depend on how the project for the cloning of ADT will go (btw @Deltakosh and @PatrickRyan where do yours stand with this project?).

Let me try to explain my point with my current case (study):

Say you create a sort of ‘sprites’ or ‘tabs’ layout in the editor such as the one I’m doing.
I have all of my ADT for meshes in a single Editor file. Each is in a distinctive container but the controls are also replicated/copied. Now, the thing I found really cool with this when starting to create my functions is that I can call on a same control name simply by calling the container. If I had a new name for all duplicated controls I would need to call on this new name for all my replicated containers/controls.

I’m not sure I did explain myself correctly here. Have a look at this draft from the editor:

Understand that the root containers in this file are used multiple times for multiple meshes in my scene.
Also understand that all these root containers also contain similar (sometimes identical) buttons that will trigger a same (replicated for the instanced mesh) interaction.

Having all these controls with the same name lets me select all from ‘controlname’ either within the file or restricted from a given container. I found this to be really convenient when creating functions for these ‘replicated controls’. Actually, I believe there’s an example of this in the GUI Editor demo for the GUI Adventure.
I guess what I’m trying to say is that it would be sad if these ‘duplicate’ controls and containers could not be accessed all together anymore. Whether it’s through the name or another identifier.

Edit: Oops, please FORGET about the above. I just forgot it does not work like this at this time (even though I spent 2 hours on it two days ago, precisely because of that… how could I forget?).
I had 2 controls with the same name in 2 different root containers and even though I was calling it from the root container, it would trigger only the first one. I even posted about it, Stupid me :crazy_face:. All I can say for my defense is that I would have so much wanted this to work like that.

So, I guess in the end, OK for the suffix and sry for the confusion. I messed things up here. :cry:

Hey, no worries :slight_smile:
I didn’t mean to offend you in any way or to underestimate your contributions. I really think they’re great :bowing_man:
I can just say that if I’ll ever dig into the GUI Editor I’ll be glad to implement your ideas :slight_smile:


Thanks for your reply. No problem here; I don’t feel offended at all. We all have our jobs, skills, strengths and weakness, don’t we?
As I often say: “Excellence starts with the understanding that you cannot be the best at everything”.
Yes, I do some code but No, I would never want to use my poor or intermediate coding skills for things I deem are really “important”. And the GUI Editor (and overall the quality of the BJS framework) is important to me. :smiley:

I would be honored if you implement some of my ideas (after having double-checked that they are indeed not just a good idea but also the way to go). Meanwhile, have a great day :sunglasses:


@mawa, one way we can be smart about the implementation of a suffix on copied controls is to give a common character to split the name from the suffix. Something like:

  • original control named button
  • pasted control named button_0
  • pasted control named button_1 etc.

Using this system, you can write code like:

let buttons = adt.getControlsByType("Button");
for (let index of buttons) {
if (buttons[index].split("_")[0] === "button") {
do something to all buttons

Basically, this says to grab all unique buttons and then split the name string on the “_” into an array. Then we are looking at the array index 0 to see if the string matches the name we want. This is a little more code than just getControlByName and doing something with the returned control. But if there are not unique control names, there will be an error anyway since getControlByName will only return one control instead of getControlsByType which returns an array. So what you were seeing in that inconsistent behavior was the fact that the input to the function was not correct since there was no guarantee that there was only a single control with any given name.

This will still allow you to be able to batch controls into doing the same thing all at once, while still preventing unexpected behavior caused by duplicate names on controls. Does that sound workable?


Yes, absolutely. Luv it :smiling_face_with_three_hearts: I actually had this idea but did not mention it for some reason (not my idea, it comes from other apps, i.e. c4d). Not to mention that if you already create a range of controls using numbers (i.e. “button0”, “button1”, “button2” then the solution of adding just the suffix without the separator character when duplicating and depending on the numbers and number of duplicates would have started to become messy).
I think this is the way to go and I would be very happy with this solution (of course, my opinion only).
Meanwhile, have a great day :sunglasses:

Ok here are mine;

Make the repo public so we can make PRs, I say that because my first suggestion is so simple I think even I could make it;

  • Round to Pixel option
    When working on GUI, I really don’t like having things land on 0.44px or be 99.98% wide.
    I understand that this (probably?) doesn’t impact performance, but it’s annoying and for people like me, I find myself going into the output of json quite often to round down and it’s just much cleaner to have it like that

  • Stop indenting copy pasted assets 10px
    Whiles this is good on paper, normally when I am copy pasting it’s inside a grid or stack panel where the added 10px really throws things off.

  • Allow us to export groups/single assets as a json file to be decoded with a .parse() later
    This is not the same as a full screen.json, but if I say select a rectangle and export it as json. I can use Rect.parse(output.json) to use it in my scene

  • Allow us to force an items transform to be % or px with a toggle (option) + bug not respecting % when used
    No idea why, but if I put in 99% sometimes it will just say 99px after I hit enter, I noticed this doesn’t happen as much if I enter 99.00%.

Sorry if this is badly formatted or sounds weird, on my phone. Will cleanup later

1 Like