Improvements to containers.

[vonflyhighace2]

Operating system or device - Godot version:
Any. Godot 2.1 stable

Issue description (what happened, and what was expected):
child nodes take on the parent containers Scale property so scaling the child node will only be overridden by the parent. creating a scalable UI is next to impossible since the child only respects the parents scale and not there own. This could be a bug but if not I would suggest having more flexibility. The ItemList node is a perfect example, why not have the grid container have similar functionality?
Steps to reproduce:
Backstory time. Needed to create a dynamic grid of buttons, so started with a boxContainer. Ran into limitations really fast with that. Tried using a grid but ran into the scaling problem. Can't use a ItemList because it only accepts Textures. Only option would be to write a custom container, not the best route for new Users. Glad I'm not a new user but ya.

Link to minimal example project (optional but very welcome):

[akien-mga]

It's hard to understand your point based on the above, could you provide an example project?

The scale of children is affected by that of their parent, but they can of course also be scaled individually.

set_scale(Vector2(0.5, 0.5))
# Current node is scaled by (0.5, 0.5), *relative to its parent*

get_node("..").set_scale(Vector2(0.2, 0.2))
# Parent node is scaled by (0.2, 0.2), *relative to its parent*
# Current node is therefore scaled by (0.5*0.2, 0.5*0.2) i.e. (0.1, 0.1) relative to its grandparent

[vnen]

I think the issue here is that a Control does not respect its scale if it's inside a container.

[ghost]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[allkhor]

Reproduced on: OS Ubuntu 16.04.4 LTS x86_64, Godot 3.0.2 stable and master 3.1 6c2d362:
Look at the code:

onready var grid = get_node("vbox/grid") # GridContainer
onready var btn = preload("res://btn.tscn")

func _ready():
----for i in range(16):
--------var inst = btn.instance()
--------inst.set_scale(Vector2(0.5,0.5))
--------grid.add_child(inst)

Buttons scale expected (0.5,0.5), but got (1,1)
Minimal project:
container_scale.zip

[alperencaliskan]

Removing this line fixes the problem. But maybe devs did this intentionally for something? If not, please fix this issue.

godot/scene/gui/container.cpp

Line 131 in f1970e1

p_child->set_scale(Vector2(1, 1));

[IceflowRE]

The line above looks like it could be removed too.

godot/scene/gui/container.cpp

Line 130 in f1970e1

p_child->set_rotation(0);

[IceflowRE]

Just removing the lines is not a good idea, because for example the GridContainer does not completely use the new scale.
The objects are 0.5 scaled, but the used margins are still 1.

Old:

OO    OO
OO    OO

OO    OO
OO    OO

4x O are one object.

If you remove the lines and use then a 0.5,0.5 scale it looks like this.

O     O
      

O     O
       

Expection would be something like this:

O  O
O  O 

[alperencaliskan]

Yes, margins are still calculated as nodes are still 1/1 scale. I did some experiments, changed size calculation in grid_container.cpp and container.cpp to make it regard node's scale. It seems to work. Can be done to the other containers.

[vonflyhighace2]

oh wow, I forgot about this thread since no one responded and containers were all still broken in 3.x series so I thought it was just a thing. This means I never used containers since they are basically useless nodes. @alperencaliskan any idea when you might push the update for commit?

[alperencaliskan]

Containers are useful for aligning and distributing nodes in a frame but a bit hard to get used to it. @vonflyhighace2 I tested on grid container only. Need to change and test other containers. I will look into others in a few days. If i can do it, i will let you know.

[Calinou]

As a workaround, you can wait for one frame or change the scale in _process():

func _ready():
	yield(get_tree(), "idle_frame")
	$HBoxContainer/Button.rect_scale = Vector2(2, 2)

[danielzting]

As a workaround, you can wait for one frame or change the scale in _process():

func _ready():
	yield(get_tree(), "idle_frame")
	$HBoxContainer/Button.rect_scale = Vector2(2, 2)

Would it be a good idea to trigger _ready() only after the node and all of its children are "placed" if the node is a Container? My conception of being "ready" (and it seems like a number of other users are being tripped up by this) is that the node is fully ready to be used, which isn't the case if its size and scale are being set by the parent. Though I would understand if this would just introduce too much complexity for its worth.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!