3 ms·
> designing UIs anywhere outside the code will eventually bite you. With Godot it is possible to design the UI in code--the editor itself uses that approach, e
by follower 6y ago
> designing UIs anywhere outside the code will eventually bite you.
With Godot it is possible to design the UI in code--the editor itself uses that approach, e.g.: https://github.com/godotengine/godot/blob/27d12092821df77a6186d2fd54055c54beefbea0/scene/gui/file_dialog.cpp#L852 https://github.com/godotengine/godot/blob/27d12092821df77a61...
> you can practically throw your version control system out of the window for UI files.
While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-/blob/master/Main.tscn https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-...
While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.
- nyanpasu64 6y agoI see what appears to be hard-coded widget positions (margin_left = 202.0). I find that hard-coding positions in desktop applications prevents layouts from adapting to different languages, font sizes and window dimensions. (Like how many Windows dialog boxes won't resize). Is this how Godot works, and is it a problem?
- follower 6y agoGodot encourages use of "Containers" for layout, which adapt to sizing/content on the fly: https://docs.godotengine.org/en/stable/getting_started/step_by_step/ui_game_user_interface.html#breaking-down-the-ui https://docs.godotengine.org/en/stable/getting_started/step_... While it is possible to hard-code widget positions, with the Container-based layout method the values in that file actually get completely ignored & recalculated on the fly. The fact that the values end up in the file at all is something I consider a bug/implementation flaw. In Godot a UI Control has an "anchor" setting for each of left/right/top/down margin which affects where the margin value is measured from in relation to the bounding box. So (hand-waving a bit here), e.g. for, say a margin value of 10px, for the left margin an anchor value of 0 means "inset 10px from the left margin of bounding box" and with anchor value of 0.5 means "move left 10px from center of bounding box" and with anchor value of 1 it calculates relative to the right-most margin. (But for right margin an anchor value of 0 means "calculate relative to right margin of bounding box, and, somewhat confusingly, I think requires the value to be negative to "inset".) What this means in practice, is that if you use an anchor value of 0 for all margins, even when you resize an element you don't need to adjust any of the margin values. Unfortunately Godot (and Containers--even though they re-calculate all the margins themselves) default to an anchor value of 0 for left margin and 1 for right margin which means the right margin is a non-zero value & gets re-calculated & updated/save every time you adjust the layout. In general the layout system works pretty well & is flexible but it does have some slightly confusing aspects (and in the past at least some implementation bugs) and is somewhat difficult to explain in text. :) (And it would definitely benefit from even more detailed documentation--than what it currently has--in terms of the "sizing flags" that determine how multiple Controls occupy/share the space available.) So, in short: Once set up correctly, Godot UI layouts generally adapt well to different text-widths, font sizes and window dimensions.