VBox, HBox, Control Elements appear to arbitrarily change without notice

Question

I apologize in advance for not being very articulate, but it's hard to describe what's happening without being a little convoltued.

I am trying to use a combination of CanvasLayer, VBoxes, HBoxes, Labels, Panels, MarginContainers and CenterContainers to make a UI layout.

Everything seems to go smoothly for the first while: I put a CanvasLayer as the root of the scene, put a VBox inside it, a label and an HBox inside that, and inside the Hbox, andother label, and another VBox, which itself has a MarginContainer, a CenterContainer, and another MarginContainer. Inside the last CenterContainer is a panel. I size everything the way I want it, and it looks like everything is as it should be.

Then, every time (and I have tried this maybe four or five different times now), the rect settings just reset, or change to different values. It appears to be completely arbitrary, although I'm sure there's some reason behind it. Once it happened when I added text to a label, another time it happened when I tried to size the panel inside the CenterContainer. From what I can assess, there doesn't seem to be a reproduceable cause (again, I know there must be a logical reason behind the problem, I just can't figure out what that is).

If I can be quite honest, it's getting rather frustrating, and I'm stumped as to what to try next. I have read the documentation for the objects I'm trying to use, and as far as I can tell, I'm using them the way they're intended.

Can anyone offer some advice? Know a good tutorial for using UI/Canvas objects? Magic spell? Anything?

Neb

Answer 1

The size and position of Control nodes are controlled by their parent (such as with layout options, expand settings, min rect size, margins, etc.). You cannot actually change any of these values. It would be better if the UI grayed them out or locked them, because it just causes glitches. However, this issue you talk about is most likely about the layout not refreshing. If you change anything, such as adding a new child, especially if there are other siblings or children under it, it doesn't always reflow. You can force it to update by hiding the root most Control node (clicking the eye icon) and then showing it again. This will then display the recalculated layout.

Fuss

Answer 2

Thanks for your reply.

I'm afraid I may not have effectively articulated my issue.

Basically, it seems like it's updating, but it's reverting all of my size changes (and ctrl-z doesn't put them back).

I tried the hide/reveal trick you suggested, but it doesn't seem to fix the issue. But since it's intended to force an update, that makes sense to me.

What I'm doing:

• Creating all nodes in the tree

• Sizing them (using the "rect" section), from root-to-child in hierarchal order

• After sizing them all, I go to populate one of the labels

• Everything reverts to the smallest size possible, and positions all shift smaller (not always to 0,0 though)

If I try to ctrl-z the most recent change, it removes the change (like label text for example) but doesn't revert the unwanted size change.

Neb

Answer 3

Yes, that's what I'm saying. You cannot change the size or position or anything, this is automatically controlled. It should just be disabled, because it doesn't work.

What you can do is change the minimum rect size, this is saved (for example if you need to add a border or margin). You can also nest Controls or use dummy "spacer" controls, but you have to let it work automatically.

Fuss

Answer 4

Oh sorry, I misunderstood.

So anywhere I'm saying "size" I should be saying "min size" and then the hide/show trick to force a check of those values?

EDIT:
Okay, so I'm now doing as above (using "min size" instead of "size") and now it's arbitrarily making things a few pixels larger than I want them.

For example: I have a Panel with a VBox as a child, which itself has a Label and HBox as a child.

The Panel has a min size of 256x144, the VBox has a min size of 256x144, the Label has a min size of 256x32, and the HBox has a min size of 256x112.

Godot is forcing the size of the VBox to 260x156 (instead of 256x144) and won't allow me to change that. It's also changing the HBox to 260x120 (instead of 256x112).

Since the min sizes of the children should add up to the size of the parent (256x(32+112)) I don't understand why it's adding these pixels.

Neb

Answer 5

I think what makes control nodes (including HBox, VBox, etc.) confusing in Godot is that they're designed to be adaptable to different window/screen sizes - if someone's playing your game on a PC they might resize the window, if they're on a mobile device the screen size may not match your default viewport. So control node parameters aren't so much areas fixed on a grid as they are rules on how things should positioned in relation to various edges (anchors) of the viewport. For example you might want something to show up on the top right, regardless of the size or aspect ratio of the window/screen the player is using. This means it will overwrite some values (like the size and position cybereality was talking about) to match the current viewport. It's confusing but also kind of necessary when you can't be certain of what size window/screen any particular user actually has.

In the examples you just cited it sounds like none of the rendered sizes are smaller than the minimum sizes you've specified, so it is respecting that setting, it's just taking other parameters into account as well.

Reviewing the official documentation on UI positioning may be helpful. You can take a look at this tutorial video as well, take it with a grain of salt (towards the end there are some parameters where the guy's just like "I don't know what this does, don't touch it" which I honestly find hilarious in a video that's supposed to be explaining how the stuff works) but it does show some good examples of how control nodes position themselves inside different viewport/parent sizes depending on how their anchors are set.

Number

Answer 6

I really appreciate the information and patience, folks.

I believe I have concluded that I.... do not like this process. 😃

It seems really easy to lose your work, and really difficult to fine-tune sizes.

Some trial-and-error is in my near future.

Neb

Answer 7

It does work, but it's super confusing, I agree. I've been using Godot for almost 3 years, and it wasn't until recently that it all made sense.

You can think of it similar to CSS with HTML design, but without absolute positioning. There are literally millions of display configurations (if you consider desktop, mobile, different resolutions, aspect ratios, orientations, etc.). And you cannot make it work if you set fixed pixel values. It might look good on your 1080p monitor, and then break on someone's 4K screen, or if they have a 16:10 monitor, or any of hundreds of phone and tablet models. So you have to change the way you think about it.

Fuss

Answer 8

You can think of it similar to CSS with HTML design, but without absolute positioning.

Aye, that's probably the closest comparison though not an exact fit either.

Astri

Answer 9

2 years for me. I took a month to build an over complex UI with a bunch of moving parts in order to figure it out. It's totally worth it.

Strangles