As a Roblox developer, it is annoying to have to deal with those curly braces that Roblox automatically puts into Size and Position. First, it doesn’t make sense because that’s not the way UDim2 reads them and second it’s annoying to deal with when you’re trying to copy and paste size or position because every time you paste them into a UDim2 constructor you have to manually remove the braces. It would even be better if when you focused the text box it removed the braces and gave you the original numbers.
Example of Size (and position) with curly braces Example of Size (and position) without curly braces
I get that the size values are different but it still doesn’t make any sense
I’ve noticed that this only occurs in GUI objects which makes it even more strange to me that it doesn’t just happen in every Instance. This can be especially annoying when trying to get something’s size or position to put into a UDim2 and having to manually take out the braces each time as I stated above.
Summary
Curly braces in Size & Position are annoying and useless and they should be removed.
Proposed Solution
Of course, remove them entirely but if Roblox is not willing to do that it would be nice when you focused the properties the braces were removed.
Curly brackets help developers see X vs Y very easily. I don’t think they should be removed.
This is mainly for developers who are new to GUI development. Having that distinction between X and Y is pretty important for young developers who are learning.
Yes you could argue that “better tutorials would solve this problem,” however, young developers learn best by playing around with stuff on their own and not from tutorials in my experience.
Then why not have UDim2 read them correctly? It can confuse players new to development why they can’t just copy and paste these values; why they have to remove them every time.
I agree that UDim2 should appear in the 0,0,0,0 form when coping and pasting for ease of scripting.
The properties menu is meant to be a visual representation of data. Grouping them in brackets makes sense in the menu, but not in code due to syntax restrictions.
I understand but if that were to be true that Roblox was trying to make it easier to read and such then why wouldn’t they do it for properties like SliceCenter? It may be a Rect, not a UDim2 but it would make sense if this was their goal.
In the case of UDim 2, its wrapping elements of the same axis together. In the case of Rect, there arent two similar axis near each other. If they used the bracket method on Rect, users might intuitively assume that its a UDim2 value
It doesn’t make sense why they should be unique to UDim2 even though Rect shares nearly the same values of X and Y.
They shouldn’t think the braces mean it’s a UDim2 value because they’re never defined that way. UDim2 doesn’t recognize them as a UDim2 value, therefore, there is no reason they should even exist in the first place and there wouldn’t be a question about it. Rect has 4 values just like UDim2 does if they share the same properties or not. If the curly braces are truly meant to help people read them then why wouldn’t they help people read a Rect? It’s not a question about what they are its why they are.
Can I make the argument that it’s been this way for many many years and would be confusing to suddenly change it now?
And then add the following points on topics discussed:
The set up makes intuitive sense once you understand what scale and offset are.
{xScale, xOffSet}, {yScale, yOffSet}
as other have said, the braces show clear groupings for each axis.
Comparative to Rects which are
x1, y1, x2, y2
Rects represent, numerically, different type/use of data compared to UDim2 (that’s to say Rects are 4 offset-like coordinates where as UDim2 is 2 scales and 2 offsets) and it would be confusing to have them formatted the same, if you were a new user and didn’t realise how they already formatted.
You could probably argue formatting (x1, y1), (x2, y2) would be a better format for Rects.
You can also argue the same for other data types that the value represented in properties isn’t accepted as a constructor.
One example would be a checkbox, the Unicode symbols for checks aren’t accepted as an alternate for true.
And Instance references like Parent, isn’t going to be a full address from game or workspace as you may do in a script, but just the name of that instance.
The most confusing (imo) would be Color3. Color3 uses floats 0-1 to represent each rgb amount, having specifically use Color3.fromRGB to use it from a 0-255 standpoint as represented in properties.
It’s not hard at all to remember the first number is X and the second number is Y. Moreover, when programming, you don’t get brackets so 99% of young developers have to learn this anyway.
Studio also has a built-in UI editor that lets non-programmers drag elements around. As a result, only programmers are ever going to manually work with the Size and Position properties.
Lastly, I distinctly remember the curly brackets confusing me when I was young. I expected to be able to copy/paste from the properties window and have my code work.
Im seeing a lot of dispute over the pros and cons so id like to offer an alternate idea that suits everyone’s needs.
What if the display includes brackets, however upon selection the blacks are removed leaving it as just the numbers? This way its ‘Easy to tell apart X from Y’ in addition to being easy to copy paste into scripts, I believe some properties already have a similar function.
The current format actually reflects the structure of a UDim2 instances pretty well.
A UDim object has Scale and Offset properties. And a UDim2 object is composed of 2 of these-
as the properties X and Y. They can be indexed like:
UI_Object.Size.X.Scale
UI_Object.Position.Y.Offset
UDim2 Instances also have two constructors, the first you’re probably more familiar with the first.
If a UDim2 object were to be represented completely in hows it’s constructed you would have {'X'={'Scale'=0.5, 'Offset'=30}, 'Y'={'Scale'=0,'Offset'=100}}.
So I don’t think removing the curly braces would be beneficial when viewing, but when editing and copying UDim2s in Explorer it would be worthwhile to reflect the UDim2.new constructors.
