Some help to understand SizeFlags?

alex_sandalex_sand Posts: 7Member
in GUI

Hi forum,
It seems I could need some help to understand what SizeFlags is actually suppose to do.

I have a control node, whose single child is a VBoxContainer.
I would like this child to have a size equal to its parent, so my understanding was I could achieve it by:

        var container = GetNode<VBoxContainer>("VBoxContainer");
        container.SizeFlagsHorizontal = (int)SizeFlags.Expand; 
        container.SizeFlagsVertical = (int)SizeFlags.Expand;

Problem: it just does not work. My root is sized 1000x500, the container stays at 40x40.

So I have 3 questions:

  • Why is it not the case?
  • How can I get this behavior?
  • and bonus question, what is the difference between Expand and Fill ? ( according to the doc, Fill takes all available space without pushing other nodes, Expand takes all the space and push other nodes, so ExpandFill does what exactly ? )

Thanks a lot for some hints!

PS: here is my minimal example.

[gd_scene load_steps=2 format=2]

[ext_resource path="res://TestScene.cs" type="Script" id=1]

[node name="TestScene" type="Container"]
margin_right = 40.0
margin_bottom = 40.0
script = ExtResource( 1 )
__meta__ = {
"_edit_use_anchors_": false
}

[node name="VBoxContainer" type="VBoxContainer" parent="."]
margin_right = 40.0
margin_bottom = 40.0



using Godot;
using System;

public class TestScene : Container
{
    public override void _Ready()
    {
        this.RectMinSize = new Vector2(1000,500);
        var container = GetNode<VBoxContainer>("VBoxContainer");
        container.SizeFlagsHorizontal = (int)SizeFlags.Fill;
        container.SizeFlagsVertical = (int)SizeFlags.Fill;

        container.AddChild( new Label() );

    }
    int frameId = 0;
    public override void _Process(float delta)
    {
        frameId += 1;
        if (frameId == 100) // make sure cntainer add time to resize
        {
            var container = GetNode<VBoxContainer>("VBoxContainer");
            GD.Print("container size " + container.RectSize);
            var parent = container.GetParent() as Control;
            GD.Print("parent size " + parent.RectSize);
        }
    }
}

Comments

  • TwistedTwiglegTwistedTwigleg Posts: 4,855Admin

    You are correct that setting it to expand should make it take the entire space. I think you also have to have fill enabled as well though, which may be why it is not working.

    As far as what each does, I believe fill makes it take up the space inside it's own rectangle, while expand makes it resize to take up space in the parent Control node. This is why fill is enabled by default but expand is not. That said, I haven't really looked at the technical side of how it works and what I wrote is just based on my observations, so please take it with a grain of salt :smile:

  • alex_sandalex_sand Posts: 7Member

    Hi, thanks for this answer.
    So if I reformulate, "expand" reserves a rectangle space in the parent container, but does not necessarily fills it ? That does explain what "expandfill" should do.
    However, I also tried "expandfill", and it did not solve the issue.
    So I made more tests, here is what I observed:

    • It actually depends on the type on the parent . "expandfill " seems to work as expected when the parent node is HBoxContainer or PanelContainer. It does NOT work when the parent is either Container or ViewportContainer (I did not check other types)
    • for simple container (or viewportcontainer) , problem may be solved by instead setting anchors (ie AnchorLeft=0; AnchorRight=1; ... on the child)

    So I have now a few follow-up questions:

    • Which containers exactly use the sizeflag of the child?
    • Does the other totally ignore those flags, or is the behavior more complicated?
    • Does the containers which respect the sizeflag ignore the anchors, or else how do they mix sizeflag information with anchors?
    • Is there some doc somewhere? (Or maybe "the doc is the code", but then a link to the code might help! even if my C++ skills might need to be refreshed)

    Thanks for any hints you could have! ;)

  • TwistedTwiglegTwistedTwigleg Posts: 4,855Admin

    Interesting! So it sounds like perhaps my understanding of it was not correct.

    To answer some of the follow up questions:

    Which containers exactly use the sizeflag of the child?

    I know that the HBoxContainer, VBoxContainer and GridContainer nodes all use the size flags correctly, as that's the only places I have used them and they seem to work fine. I have only set it up in the Godot editor though.

    Does the other totally ignore those flags, or is the behavior more complicated?

    I'm not sure, sorry!

    Does the containers which respect the sizeflag ignore the anchors, or else how do they mix sizeflag information with anchors?

    While I'm not totally sure, my hunch is that it may act like margins, providing an offset after the resize due to the sizeflag, though I haven't really tried or thought about it until now, so I'm not sure...

    Is there some doc somewhere? (Or maybe "the doc is the code", but then a link to the code might help! even if my C++ skills might need to be refreshed)

    Here's a page on the documentation about Control nodes and containers, which touches on the size flags: Containers

    Based on the documentation, it may be that only nodes that extend the Container base Control class work with size flags? I could have sworn I have used size flags with just a normal Control node, but maybe I'm getting it messed up with anchors...

  • alex_sandalex_sand Posts: 7Member

    Thanks! I had missed this page, indeed it clarifies a bit which flags are respected by each type of container.

  • woopdeedoowoopdeedoo Posts: 138Member

    Different containers serve different purposes, so the behavior will vary, but, put simply, if the root is not a container then it won't ever sort out it's children automatically, and so it will also not expand any nodes. The top most container in the hierarchy has to be manually set to some size. You'll have to, for example, do the equivalent to setting Layout->Full Rect from the editor (I don't know it from code). Children of that container will be sorted out automatically according to the container's behavior and the flags you set on its children.

    Most containers will expand your nodes in some predictable way, but some specific ones may not even touch them. For example, the ViewportContainer will only care about Viewports. A simple Container is merely a base class with no set behavior, so it does nothing about its children.

  • LakeLake Posts: 60Member

    I don't suppose anyone looking at these issues can explain which settings will cause a container to assume the smallest size possible vertically that still holds all of its contents.

  • MegalomaniakMegalomaniak Posts: 4,034Admin

    Don't forget to also take advantage of anchors and margins.

  • Vale-gitVale-git Posts: 198Member

    I have to say: Devs have no idea at all how to give enough documentation for anything they do in this game engine.. Seems if them are gong to write 2~3 rows of comment they are going to die right the next day!

    People add some code and that's it.. WHO CARE if someone else need to use it!
    In my opinion they don't deserve be called developers! I'm ashamed to be part of developers myself too :(

    I'm so disappointed of this level of developer in our planet! We not deserve to be a multi planetary species...

  • TwistedTwiglegTwistedTwigleg Posts: 4,855Admin

    @Vale-git said:
    I have to say: Devs have no idea at all how to give enough documentation for anything they do in this game engine.. Seems if them are gong to write 2~3 rows of comment they are going to die right the next day!

    People add some code and that's it.. WHO CARE if someone else need to use it!
    In my opinion they don't deserve be called developers! I'm ashamed to be part of developers myself too :(

    I'm so disappointed of this level of developer in our planet! We not deserve to be a multi planetary species...

    I do not think it's matter of care per say, I think it's more time, resources, and energy. Most of the developers on Godot are volunteers and work on Godot in their spare time, so they don't always have the time to sit down and write documentation. On top of that, many features are pulled in with the plan of more thorough documentation being added later, but unfortunately things get in the way or new features need to be worked on, so it slides and gets put on the back burner.

    One of the other issues is, because the developer writing the documentation is so familiar with the source material, it seems natural how it works and it's easy to forget that others might not have that same experience. It can be really hard to see something you worked on so closely from the eyes of someone who doesn't have the same close knowledge of the particular system in question. I know I've had that issue a few times and it made it much harder to write.

    What I would highly recommend doing is making issues on the Godot documentation and try to clearly explain what detail(s) you think are missing or should be expanded. That way developers can see it and try to improve the documentation, making it better for everyone. :smile:

    On an aside: I do not think considering those who do not write detailed documentation to be "not developers" is going to help the situation. I understand being frustrated, but I think it's best to focus the situation, what might be causing it, and how it can be improved. That way, the feedback can be more easily evaluated and taken into consideration.

  • Vale-gitVale-git Posts: 198Member

    I do not think it's matter of care per say, I think it's more time, resources, and energy. Most of the developers on Godot are volunteers and work on Godot in their spare time, so they don't always have the time to sit down and write documentation. On top of that, many features are pulled in with the plan of more thorough documentation being added later, but unfortunately things get in the way or new features need to be worked on, so it slides and gets put on the back burner.

    >

    Same issue when someone think to refactoring code.. It have to be done at same time.. Or never. Its a classic problem in IT :))

    One of the other issues is, because the developer writing the documentation is so familiar with the source material, it seems natural how it works and it's easy to forget that others might not have that same experience. It can be really hard to see something you worked on so closely from the eyes of someone who doesn't have the same close knowledge of the particular system in question. I know I've had that issue a few times and it made it much harder to write.

    >

    Yes . Exactly what I was pointed out. Devs need to think more often to other people. (As infj came natural to me and I understand other have a different mind set but exactly for this reason we need to put in place some rules to avoid this problem - we have already rules for coding, just add 1 little rule to add docs for other people to understand what we do, is so simple ...)

    What I would highly recommend doing is making issues on the Godot documentation and try to clearly explain what detail(s) you think are missing or should be expanded. That way developers can see it and try to improve the documentation, making it better for everyone. :smile:

    >

    we already do that as much we can. BUT why we need to cover other gaps when is far more simple and correct to fix the problem at source?

    On an aside: I do not think considering those who do not write detailed documentation to be "not developers" is going to help the situation. I understand being frustrated, but I think it's best to focus the situation, what might be causing it, and how it can be improved. That way, the feedback can be more easily evaluated and taken into consideration.

    Its a small step in the right direction to think a bit more to other people. Having knowledge is useful as long is shared..

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file