I find that the “BackgroundTransparency” property shouldn’t affect the transparency of the border, but instead the border should have its own transparency option. It kind of sucks when you’re making UI that has a lot of transparent buttons or text labels that need a solid crisp border but a slightly transparent background. There are obvious workarounds for this but that’s just extra work that can be avoided…
At this point retroactively changing this would break almost every UI in existence so I don’t see this kind of change happening unfortunately. Perhaps there’s a different way to implement it that wouldn’t break existing ui.
Could make a new “UI” element named “BorderFrame”, since you can’t make a solid border with a complete transparent background, since the border would just vanish with it.
Something like this could be neat to have along with support for parameters such as border radius.
Suggested this in the past
But yeah, it would have to be some new object
You could prevent it from breaking old GUIs checking if it’s saved a BorderTransparency property. If not, it sets BorderTransparency to the value of BackgroundTransparency.
No because if you separate BackgroundTransparency from BorderTransparency, then it’ll still break games who adjust the BackgroundTransparency as part of the game to suddenly have borders remain.
This is probably true, but if this is the only problem, wouldn’t a boolean value solve this? Checking this box would allow you to have the Background and Border have separate transparency properties. By default this should not be checked, therefore the border transparency would be set to the same value that the background transparency is, keeping games with translucent background and borders invisible.
That sounds like it would be a pain to deal with in the future. No, a BorderFrame instance is probably the best solution.
I too would go for a BorderFrame object. I think this should have image fields for a nine-slice system. (?)