Godot-proposals: Expose `filled`, `width` and `antialiased` properties in the `ColorRect` class

[Xrayez]

Describe the project you are working on:
Goost Godot Engine extension.

Describe the problem or limitation you are having in your project:
The current ColorRect class is not versatile enough.

The core functionality behind this class is provided by CanvasItem.draw_rect() method, which also allows to:

• draw a filled rectangle or just a contour of it;
• specify the width of a rectangle (only applicable for contours);
• draw an antialiased rectangle (only applicable for contours).

It's not possible to do the above with the current ColorRect class.

For instance, the antialiased property is part of Polygon2D, although this might be only relevant for Godot 3.2.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I propose to expose the hidden functionality behind ColorRect. I can do this myself.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Just expose those parameters as properties in ColorRect, it should be trivial to implement.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It's possible to create an equivalent class via script.

Is there a reason why this should be core and not an add-on in the asset library?:
It's about exposing existing functionality which is currently unavailable in ColorRect for scripting purposes, so this would only complement the engine.

[Calinou]

draw an antialiased rectangle (only applicable for contours).

In case someone is wondering what this is useful for, keep in mind Control nodes can be rotated :slightly_smiling_face:

[KoBeWi]

Looking at the linked PRs, ReferenceRect and ColorRect are very similar. Maybe they could be merged into one node?

[Xrayez]

@KoBeWi I thought the same, but perhaps they exist to cater concrete use cases rather than what raw API provides, perhaps it would be too general-purpose to merge those classes, have to ask @groud.

Yet they use the same CanvasItem.draw_rect() API to achieve different things. Also, only ReferenceRect has editor_only property, while ColorRect has no such property, so merging those classes would potentially mean taking the best from both worlds.

The only difference between ColorRect and ReferenceRect is that they switch the filled parameter in draw_rect. 😃

Also the antialiased property which could be added to a new merged class. In theory, it would be enough to merge all the functionality from ReferenceRect to ColorRect without coming up with a different class name.

And by the way, the ColorRect class as it is now can be replicated via GDScript with the following code (3.2):

tool
class_name ColoredRect extends Control

export(Color) var color = Color(1, 1, 1) setget set_color

func set_color(p_color: Color):
    color = p_color
    update()

func _draw():
    draw_rect(Rect2(Vector2(), rect_size), color)

[KoBeWi]

I thought the same, but perhaps they exist to cater concrete use cases rather than what raw API provides, perhaps it would be too general-purpose to merge those classes

The thing is, from my experience, I ever used the ReferenceRect less than few times. I actually found a real use for it just recently. On the other hand, I use ColorRect very often. So ReferenceRect is just not really worth keeping, given it's limited use cases.

Also the merged node could be called PlainRect or something.

[Xrayez]

Yeah I'd just remove ReferenceRect for that matter, I've never actually used this class myself either (likely just not developing sophisticated UI extensively yet...)

The downside I see is that if you do use ReferenceRect often, then you'd have to switch off the filled property in the new class every time. ColorRect is also likely used more often in a real game as seen in the "Dodge The Creeps" tutorial, so editor_only would have to be disabled by default, which is not the case for ReferenceRect currently, so again you'd have to be careful not showing the border in a real game if those are only used for development purposes.

[Xrayez]

Also the merged node could be called PlainRect or something.

Poll

React to this post with any emoji to choose your preference for the new class for drawing rectangles! (Assuming we remove the existing ReferenceRect class and merge it into a new one).

• [ ] 🚀 if you like ColorRect (current)
• [ ] 🎉 if you like PlainRect
• [ ] 👀 if you like DrawRect
• [ ] ❤️ if you like VisualRect
• [ ] 😄 if you like CanvasRect

Feel free to create your own poll in a new post for other suggestions.

[groud]

@KoBeWi I thought the same, but perhaps they exist to cater concrete use cases rather than what raw API provides, perhaps it would be too general-purpose to merge those classes, have to ask @groud.

Hmm, I would say merging makes more sense. I see little use cases for ReferenceRect, while ColorRect works well as a placeholder or for plain background color.

We would have to set a limit on what feature to add though, I don't want the new node to become an equivalent feature-wise of Panel node with a StyleBoxFlat style (which supports rounded corners, shadows, etc...). If we keep the node simple the idea sounds good to me. :)

[Xrayez]

The scope of this class would be limited by CanvasItem.draw_rect(). Simply exposing these parameters as properties would be Necessary and Sufficient™ to implement this proposal. 😛

And of course documentation can clearly define the scope, and even mention that it provides the full functionality behind draw_rect() to make this explicit.

Yet godotengine/godot#42906, godotengine/godot#42907 might still be worth to cherry-pick to 3.2.

[Xrayez]

@groud could you please test/review/approve godotengine/godot#42931?