Hi everyone, I’m using the BabylonJS GUI Editor to create an overlay for my scene, and import it easily into my project for faster iteration. While it’s not complete, I’ve noticed that simply importing the JSON file into my project has all the textBlocks in my StackPanel slightly offset to the right by a slight margin, which causes the text to be clipped by the scrollViewer. The TextBlocks aren’t modified manually in any way in the Playground.
I have no idea what could be causing this. I’ve tried toggling the “Only Pad Descendants” bool in the inspector of the stackPanel, as it seems to be the only setting linked to their alignement, but it doesn’t work. I’ve also tried reapplying a counter-offeset manually in my project, but this seems very inconvenient on an UI with many elements like the one in my playground. I don’t know if the stackPanel is to blame or if it is the overall structure of my UI that is faulty. Any suggestions would be welcome.
From what I know, there’s some sort of issue stacking TBs. There’s also an issue with the Editor not allowing to define no value for the width or height of a stackpanel. Things that work with code eventually don’t work from the Editor becomes of some restrictions towards the input values and the use of percentage VS pixels.
I know it might look a bit cumbersome but (as of today) the way I found to fix this issue, using the Editor is to constrain each TB inside a container (usually a rectangle). That works, but the set-up is a bit tedious
EDIT: I remember having posted around this about a year ago. Obviously didn’t get very lucky with this request to fix
I did a pretty deep usage of StackPanels inside ScrollViewers in the BabylonChat project, and didn’t have this issues (I had others , don’t worry). But like @mawa notices, I think I mainly inserted rectangles, instead of directly inserting TBs.
That said, I’m not familial with the GUI editor (I did the chat only using code), but having a look at your links, I’m quite surprised :
On my side I have the indentation on both Playground and GUI editor (it seems that PG adds nothing which is not in the editor, on my side)
Having a look at the textBlocks in the editor, they all have a hardcoded padding on X, which seems to be the reason of the shift :
Haha! Yes, nice you spotted that. I didn’t return to this part in the Editor in a while. It actually looks like it works (without the need of adding rectangles anymore )
FYI: I believe I know where the padding might come from. When you copy a control in the Editor, It sets a padding of +10px (to be able to distinguish it from the original, so I have been told… although I don’t really like this solution). Make a copy of the copy and you’ll get 20px and so on… In the PG some have up to 50px padding. So, there you go
No, this wasn’t intended. I noticed it this morning right before checking the forums for an answer. I feel kinda dumb when stuff like this happens lol.
Thank you for your time. I should have been more cautious with my layout. I find it strange the offset is there in the first place, since I don’t recall ever manually positioning my texts like this.
When you copy a control in the Editor, It sets a padding of +10px (to be able to distinguish it from the original, so I have been told… although I don’t really like this solution). Make a copy of the copy and you’ll get 20px and so on… In the PG some have up to 50px padding. So, there you go
Well, this explains a lot. Quite annoying to be honest, this shouldn’t be there in the first place.
Simply select a control, use control+C / control+V to copy paste.
And I actually discussed this with @PatrickRyan about a 1 year ago and from my understanding it is ‘per design’ and apparently there was no desire to change this.
At the time of building the editor, we did a breakdown of many of the tools that UI designers were using at the time (Figma, XD, Illustrator, etc). If I remember correctly, most of them did some sort of offset for pasted controls so the user had some feedback that the paste action actually worked. The reasoning is, if the user copies and pastes a control, they need to move it anyway as most of the time controls will not be laying directly over identical controls, so dragging it back inline with the original control wouldn’t be an issue. We also assumed we would have gotten snapping between controls for alignment, but that feature was cut for time and we haven’t been able to fund any more work on the editor.
I just checked again and Figma and XD are pasting directly over the original. If you are paying attention to the layer stack you can see the new control. In XD, the layer stack isn’t the default view so that’s a little hidden. In Illustrator, the offset on a paste is still there, but Illustrator has a shortcut to paste in place which is shift + ctrl + v (cmd on Mac) which will paste the new control exactly where the original is.
Ideally, we would have some sort of visual feedback that the paste did work right on the control (outline, highlight, temp icon, etc.) and then it would not need an offset to show the paste worked. Ideally, we would also have some sort of alignment snapping as well. We can certainly change the behavior to not add the offset or add a similar shortcut like shift + paste to paste in place. If the other UI-first design tools are not offsetting on paste, it makes sense we follow suit, but I am still concerned about users not seeing a visual change on the control when pasting. Even something as simple as delaying the selection of the new control by half a second would queue the user into an action happening rather than seeing no change on the control.
Hope you are well and had some time for holidays
Indeed, I recall that this is what we shortly discussed at some point.
I think the reference to AI is may be not all that relevant. AI isn’t really a tool for UI. Although it serves as a base (and I sometimes use it for that). It’s essentially a vector drawing tool and - as you say - it has all sorts of shortcuts for fast building.
Hum? Honestly, I’m not sure about that. Since you can also copy containers with the entire hierarchy. Which is something that’s really great, btw. Users should also note that in case you copy the hierarchy, only the first element (the container) is offseted. While all children remain in place. So this makes it really nice for productivity. I’m happy with this part.
Well, here I would renew my suggestion. If you recall it, my suggestion was to change the name of the copied control/container. Adding to the name something like ‘_1’ or ‘_copy’ or ‘.1’.
Basically, my two cents for this are that if (as you say) it is unlikely you want to have the control (or container) pasted right on top of the original - it is also highly recommended to rename it. Since two or more controls with the same name will create a conflict when you start creating functions to interact with these controls (through name). And then, in a complex GUI (with lots of controls) you will eventually not even notice that it is breaking simply because you have a duplicate name of this control (happened to me a number of times). So now, the first thing I do when copying a control is to rename it (and next, I use TAB twice to move to padding-left and enter 0 and TAB again for padding-top and enter 0). That’s the part which I find a bit cumbersome to use (personal opinion of course).
I would not upvote any of these solutions.
EDIT: Just to make this clear regarding my suggestion for renaming the copied control or container. What I suggest is that it renames only the copied object (control or container) - not the entire hierarchy in case of a copied container/parent. Eventually, the user would want to keep with all names of controls and access them through the parent. In which case, needing to rename all controls again would be a bother and a waste of time. Of course, even better, would be that when attempting to copy/clone a hierarchy, the user would get the option to increment the naming of all children (with a default set to ‘no, don’t rename’).
Hey, @mawa, I did get some time away. Thanks for asking!
In the legacy sense, before 2015/2016 when XD and Figma released which pushed this wave of UI tools, all of the designers I was working with (including me) were creating UI in Illustrator simply because it was fast to iterate and you didn’t run into raster issues with the inevitable revisions that were coming your way. All of the design teams I work with have since switched to Figma once they had a full enterprise story, but at the time I was designing these flows, I was still considering Illustrator as a legacy tool because of the common familiarity with UX patterns.
What I was talking about with auto alignment was more about when you copy/paste any control or hierarchy of controls and start moving the copy, we would have an option to snap alignment (horizontal or vertical) automatically with siblings at the same level in the hierarchy. This would allow the user to move a control that has been offset to snap to left/right alignment or top/bottom alignment with a nearby control. This is similar to smart guides or snapping seen in many apps. This was meant not only to help with alignment in general, but as a remedy for the paste offset. Unfortunately, that feature got cut due to resource limits.
I agree, this should be default to change the name and this needs to be added (@RaananW?). My concern was more for user feedback in the line of sight when copying. If you select from the tree view and copy/paste, you see a change. However, if you select the control on the artboard and copy/paste, without the offset you see no change. This is where I think we need some sort of visual queue that something actually happened without either looking to the tree view or dragging the control to see if it worked. Remember, we have no undo stack yet so if the copy didn’t happen (missed the key for example) and you grab the original and move it, it has to be manually placed back in its original position.
I agree that the copied control should be the one that has the suffix added to the name. This happens in a lot of apps that I use where children retain their original name. This can also become a sticking point if you need to have unique names for the children as well. I would +1 the abillity to choose how the controls are named. Sort of a Paste Special action. The normal copy/paste would just add a simple suffix on the control that the user can rename. Paste Special should give options not only to renamte only the parent, but also the children, and set a custom suffix to be added to all. This would need to be a pop-up interaction so the user can interact to select parent or parent/children and then be able to enter a custom suffix. This is why I would suggest this as a separate type of paste action (maybe shift + ctrl + v as well as in the menu) so that simple copy/paste is quick and dirty, but the user has an option to have a more robust version.
Thanks for taking more time to return to this. First, I’d like to stress out here that I find the GUI Editor to be a very nice tool to fast build a UI in BJS (and easily maintain it). While it might still (and always) can do with improvements, I’d like it to keep with its simplicity of use and straight forward and both ‘sketching’ and ‘productivity’ oriented unique advantages.
Yes, and so was I. And I still use it regularly for this. I guess it’s my bad english again getting in the way What I wanted to say is: Sure you do not want to reproduce Illustrator? Honestly, I do not know of how other users use the GUI Editor. All I can tell you is how I use it and why I like it. Before using the Editor, I first started create my GUI for BJS using code. I tried to always use the BJS 2D (and 3D) gui. So, I believe I mostly know of how it works in general and the different properties and values you can set.
With this, coming to the editor, I mostly still build everything using just the hierarchy and the properties panels. Read I very rarely scale or position controls from the artboard. I use it mostly just to confirm that my input is correct. As opposed to this method, when using I.E. Illustrator, I work mostly from the visual. I set grid and rulers with snapping and use shortcuts to duplicate and pick objects and snap to move things around. That’s two very different ways of building.
Now, you mentioned budget/funding. If I had to make a choice between pushing either method (visual building and tools VS properties), I would rather think that it is easier and likely more appropriate to continue to essentially work the aspect of ‘coding through an editor with visual representation’, rather than the other way round. Of course, again, personal opinion only.
, don’t worry). But like 
)
What I wanted to say is: Sure you do not want to reproduce Illustrator? Honestly, I do not know of how other users use the GUI Editor. All I can tell you is how I use it and why I like it. Before using the Editor, I first started create my GUI for BJS using code. I tried to always use the BJS 2D (and 3D) gui. So, I believe I mostly know of how it works in general and the different properties and values you can set.
this as well. That would be a great addition 