Godot-proposals: Allow users to set the origin of Control Nodes

[golddotasksquestions]

Describe the project you are working on:
Card game, Action game with items, menus.

Describe the problem or limitation you are having in your project:
When working on menus, anything with drag'n'drop functionality, items, cards, or even a simple debug text label, I find myself in dire need to have control over the Control nodes origin every single time.
I work with a Control nodes as well as those inheriting from Control, but Godot currently does not seem to offer a way to adjust the origin. rect_pivot_offset is not an option since it is an absolute value (pixels I assume), not a percentage.
The default origin for all Control nodes is the top right corner. This makes centering and scaling and positioning incredibly tedious and unintuitive.

Describe how this feature / enhancement will help you overcome this problem or limitation:
Controling scale, positioning and grow direction is currently a nightmare from UX perspective. It forces you to use multiple nested nodes and properties of those nodes and absolut pixel values.
This proposal would reduce all that to just one single setting.

Personally I would think having the origin of Control nodes and Node2Ds work the same way would be the solution, even if they have different defaults (top left vs centered) and Control nodes having additional parameters like padding/margins.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:
I don't know any C++
Edit:
Something similar has apparently been proposed and requested here:
https://github.com/godotengine/godot/issues/19529
PR: https://github.com/godotengine/godot/pull/30305

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It's the first thing I would want to adjust every single time I work with any kind Node that inherits from Control, so yes, it would be used often.

Is there a reason why this should be core and not an add-on in the asset library?:
It's mainly a (massive) UI/UX improvement of existing features.

[hammeron-art]

That's what Pivot Offset is for. The main issue is that it doesn't update automatically. It should work like size and margin which update when related properties change.

Predefined origins like the screenshot will add another limitation. It must be values. I do agree it could be percentages like the anchors but there is a way of implementing it without breaking compatibility. Keep Pivot Offset as it is and add _Pivot Modes_ such as _Keep Position_ (current behavior) and _Proportional Scale_ (update pivot when related properties change).

[golddotasksquestions]

@hammeron-art
No, my main issue is the user experience and this backwards design principle. Making Pivot Offset change automatically might help with the negative symptoms short term, but the inherently bad design of the user experience still prevails. No halve way decent software with layout capabilities has such an incredibly hard to grasp and seemingly pointless backwards workflow. And at the core of this all is the fixed origin position.

If the user does not want the origin to be in the top left corner, the user should be able to set it somewhere else.

If having it set to the top left corner is so important for inert engine reasons, then why for the love of transistors have it not this way throughout the engine, including all Nodes inheriting from the Node2D? This mixed system is really the worst of all options.

[hammeron-art]

If the user does not want the origin to be in the top left corner, the user should be able to set it somewhere else.

I'm not understanding your reasoning. The origin isn't the left corner but the pivot offset. If you want the origin at the center, set the pivot offset to the rect size*0.5. You would have to set the pivot once and the automatic update would keep it at the center when the rect size changes. It's the same effect as using percentage.

[golddotasksquestions]

Imagine a centered or right aligned Label you cast some text to. Every time the text length changes, the Pivot Offset value will have to automatically change as well. Do you think this is good design?

[hammeron-art]

I agreed from the start that percentage for UI is better. My suggestion of auto-update is just a way of keeping compatibility or if they are not interested in changing the current design. The size and margin already work like this so it makes sense to make the pivot works like this as well.

[lentsius-bark]

I'd like to chip in to say that even if the proposed solution is not the best approach, I do hope the pivot editing options gets an update for UI. I for one remember playing with horizontal and vertical growth and pivot position to achieve desired UI functionality which took me a lot of testing and fiddling, which done with percentages would have been a single click away.

[vitorbalbio]

I'm also having problems with that since there's no way to set the Control origin for translation other than the left superior corner. So i need to parent it to another control with size 0 that will work as a pivot point.

[HybridEidolon]

I am working on some controls for a game UI using the Control hierarchy. While the container system works great for conventional desktop UIs, the lack of an "origin" makes it difficult to use for Controls that are free-standing in screen space. For example, I want to be able to programmatically place a speech dialog at a specific location on-screen, with its origin being a point between two PanelContainers in a VBoxContainer. This is surprisingly hard to accomplish with the current system, especially if the Control changes size at all (e.g. the text shown resizes its sub-container).

[kilojool]

I also would like some way to change the origin of control nodes. If the pivot offset affected position also, then that would be enough for me. Not sure if that would cause other problems though.