GUI Editor Bugs from Editing

Dears,
I have two new bugs to report:

  1. REMOVING a row or column from a GRID container with assigned control(s) to the removed row or column causes a BLANK SCREEN CRASH the next time you select this control from the tree.

  2. Duplicating/Copying a control inside a container (rectangle, stackpanel or grid) causes the COPIED CONTROL to have 10px ADDED TO ITS X AND Y POSITION.

Thanks in advance for investigating on these and have a great day :sunglasses:

cc @carolhmj

1 Like

Thanks as always for catching these things! :saluting_face:

This was actually an intentional change added to help distinguish between copied and pasted controls, but if it’s confusing to users we will need to iterate on the design @PatrickRyan

PR up for the first bug :dancer: Fix a bug where deleting a row/column with a control inside wouldn’t … by carolhmj · Pull Request #12890 · BabylonJS/Babylon.js (github.com)

1 Like

Thanks. Now given your answer and @PatrickRyan, may I just make a simple suggestion?
What about changing the name of the copied element, adding an incremental number to the element name. Where ‘button’ would become ‘button0’, the next duplicate ‘button1’ and so on.
We are already used to this in 3D apps, yes? And I guess it would make sense for at least 60% of use cases (to have an incremental numbered name of a same control. And then, it’s easier and more comprehensive in a workflow to check and may be revise the element name (rather than changing its position - not to mention that +10px on X and Y is just a random offset that will next need to be changed). Again, just a suggestion but I believe it would make sense. What are your thoughts?
Thanks,

I like the idea! Makes a lot of sense.

1 Like

@PatrickRyan just bringing mawa’s suggestions to your attention :thinking:

@mawa, we should already be adding a suffix onto copied elements, so if that isn’t happening, we need to correct it. The offset on a pasted control needs to be there so that users can actually click on both the original and the copied control if needed. If we have no offset, it’s hard to tell if something actually happened if only looking at the canvas and you can’t select the original without moving the copy. It would likely be a rare occasion to want a copy of a control in the exact position of the original, so the user will need to move it anyway after pasting. Lastly, we wanted to borrow from learned UX other layout software in which case a pasted element usually has a slight offset so the user can see the action has happened. It seems from this learned UX, that users won’t question why a pasted control has a slight offset from the original.

I can take this answer and it does make sense to me. It’s not really a big deal to set the new position on a duplicate so if it helps the UX, that’s fine by me. Thanks for taking the time to answer (in broad details, as always :smiley: Have a great day :sunglasses:

1 Like