Renames: align to horizontal_alignment, valign to vertical_alignment, *Container/Tabs alignment, related

[nathanfranke]

See: #54161 (no comment AFAIK)

Also unifies the repeated enums in different classes such as Label, Button, etc.

[YuriSizov]

So in all those classes that didn't have horizontal fill option, does this introduce an undefined behavior now?

[nathanfranke]

So in all those classes that didn't have horizontal fill option, does this introduce an undefined behavior now?

Looks like most classes add FILL as an alias of LEFT, so I did that for the rest of the switch statements.

[nathanfranke]

Any ideas on why the static check is failing? Even if I change the type to "Error" it shows "ERROR: Unresolved type 'Error', file: Button"

[YuriSizov]

Any ideas on why the static check is failing? Even if I change the type to "Error" it shows "ERROR: Unresolved type 'Error', file: Button"

I think you have a typo, you refer to [HorizontalAlignment] and [enum HorizontalAlignment] there in the docs, both can't be true anyway, but I also think that neither will link properly. It should probably be [enum @GlobalScope.HorizontalAlignment].

[akien-mga]

We discussed this in a PR meeting and agreed that this makes sense.

There's a couple points that could still be worked on though:

• InlineAlign should also be renamed to InlineAlignment for consistent (or everything back to Align if we think it's enough)
• Having those definitions in math_defs.h is weird, but that was already the case before this PR. But this looks like it could be moved to a class enum in Control. The only two classes which wouldn't have access to it right away would be Font and TextParagraph, but they could likely include control.h for that?

[nathanfranke]

• Having those definitions in math_defs.h is weird, but that was already the case before this PR. But this looks like it could be moved to a class enum in Control. The only two classes which wouldn't have access to it right away would be Font and TextParagraph, but they could likely include control.h for that?

Doesn't look like it's easily possible. control.h depends on text_server.h, but now text_server.h also depends on control.h.

[akien-mga]

• Having those definitions in math_defs.h is weird, but that was already the case before this PR. But this looks like it could be moved to a class enum in Control. The only two classes which wouldn't have access to it right away would be Font and TextParagraph, but they could likely include control.h for that?

Doesn't look like it's easily possible. control.h depends on text_server.h, but now text_server.h also depends on control.h.

Maybe text_server.h is a good location for this? Not sure. WDYT @bruvzg?

[nathanfranke]

FYI InlineAlignment, BoxContainer, TabContainer, TabBar alignments are renamed. However the main enums are still in Global Scope

[bruvzg]

Maybe text_server.h is a good location for this?

I guess it make sense to move text alignment enums to the text server. It should not cause any dependency issues, but I'm not sure if it's better than global space.

[akien-mga]

Alternatively if we want to keep them in global space, I think some of the enums in math_defs.h should be moved to a new dedicated file as they have nothing to do with math.
But that's maybe out of scope for this PR.

[akien-mga]

Thanks!

[nathanfranke]

@akien-mga Uh oh! Something slipped by GH actions somehow: https://github.com/godotengine/godot/blob/master/editor/plugins/material_editor_plugin.cpp#L128

Should I make a follow up, or can you just commit a fix?

Edit: Currently testing if this line is the only error, at least when building for Linux

Edit: Resolved by 3752e8f, crisis averted