I think we should just change the way UIScale works for a more-understandable system or introduce a new constraint for the reasons above.
Size is the base size, and UIScale is a multiplier–that’s why Size has 2 axes and UIScale only has a float.
That’s the problem, Size isn’t the base size. The term ‘base size’ means that it never changes, and this is correct if you’re talking about the property itself, but visually this is extremely far from the truth. ‘Visually’ becomes a problem here because we upgrade (or fix) our UI by observing it visually. There is a very clear disconnect between the immediate information that the current Size.[X/Y].Scale has versus using pixels. Seriously - I know I’m not the only one that drops random Scale values (with a hint of what I want the value to be) until it looks somewhat right.
On the same note regarding “immediate information,” the name ‘UIScale’ is somewhat a misnomer when used in conjunction with another datatype (UDim2) with a component called the same thing in the same context but with a different-but-similar functionality; this can especially be observed in the initial release of the new UI components. With the precedence of “Scale” being used in the context of things scaling off of another GuiObject, naming the object ‘UIScale’ is a bit of a blunder. I would go so far as to rename “UIScale” to “UIScalar” or something among the line, but nothing’s stopping adding a new ScaleType Enum with fields Static and Variable and having the component default to Static for backwards compatibility.
We’re constantly implementing new UI components to effectively remove the independence of other GuiObjects:
- SizeConstraint → UIAspectRatioConstraint
- TextStrokeTransparency + TextStrokeColor3 → UIStroke
- BorderMode + BorderSizePixel + BorderColor3 → UIStroke
- ClipDescendants → CanvasGroup
We should continue this approach and never stop (within reason).
I don’t see the point in doing a half-approach with component-based UI because it makes for two layers of items to sift through which makes changing things accordingly a slog, especially when blocking things out. Remember the short time when UIStroke was implemented but BorderSizePixel was still ‘1’ at default (technically, it still is) so we had to fix those properties and then the stroke? Small, basically ineffective in the grand scheme of things, but it was unnecessary friction that doesn’t need to exist - and now, it doesn’t.
When you develop UI, you work in pixels. I think it would be much better to keep it that way by having variable scaling be controlled by a component rather than the instance itself. And honestly, I’m looking at the Selection group in those as well. Clutter-wise, why have all these blank fields instead of just adding a UI component that specifically enables the functionality of selection?
In short, I think that GuiObjects shouldn’t dance on the line of imperative and declarative. What we type in should be what we visually get every time, no matter what.