Make UI system more intuitive

[markotaht]

Describe the project you are working on:
2d management game. It has a map where your mashines and stuff are and then there is the UI where you can control everything and that gives you overview about the situation.

Describe the problem or limitation you are having in your project:
Creating a UI is turning out to be a headache as the positioning and placing UI elements is not very intuitive. And lot of time is spent on doing even the simplest UI elements.

Describe how this feature / enhancement will help you overcome this problem or limitation:
It will make creating the UI more simple and intuitive.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:
While the container system itself is a good idea, the way to place and set elements is rather difficult. So Instead of parent container overriding the child node values, the child node values should be in reference to the parent container. If parent container has a margin of 10 and child container sets the margin to 20 then the actual margin for child should be 30. And the same with other parameters. Location of child node should be in reference to parent node. Even if parent is at X 100 and child has X -40 then global position of child should be 60. Basically they behave like HTML elements, only that some of the elements have some preset behavior.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This will be used often, as it is the basis of the UI system.

Is there a reason why this should be core and not an add-on in the asset library?:
It would make it easier for people to get into Godot without having to spend tons of time researching on how it actually works. This would allow to do away with the custom constants for many elements.

[willnationsdev]

Any adjustments here would probably require a lot of work and would need to be done in the 4.0 release since, I'm guessing, it breaks compatibility with the entire editor. Not an argument against it; just emphasizing that if we do decide to make this sort of change, then we will want to work on these changes sooner rather than later as it will greatly affect the design and development of the UI for the next release.

[markotaht]

That is true, this is a big design change. It just in my mind it would make it more logical as this is the way many other thing do UI. Children override parent values or are in reference to parent values. Children use parent values only when no children values are present, or if parents have some special behaviour (aka vertical layout) where it would make sense that parent can override or at greatly influence child behaviour. But even in special cases child should have some level of control.

It might be me, but i like how Unity has done its UI system.

[Janders1800]

The only problem I could point out it is anchors are a bit confusing for starters in Godot, but once you get the hang on it, I see no problem with current UI system.

I personally had a lot of problems with how Unity handles UI, to the point of not using it for some projects (I heard they were going to drop it and move to a CSS like system), so maybe I'm a bit biased.

[SuperDIMMaX]

+Janders1800
Current system work fine. If need more, and more powerfull - suggestion add Chromium Embedded Framework - as module - it will be awesome.

[Calinou]

@SuperDIMMaX We have no plans to add a WebView of any kind into Godot. It can likely be done with a third-party C++ module though.

[markotaht]

Both Godot and Unity UI systems work but are very difficult to learn. But i could make sense out of Unity UI system after a while. I have yet to comprehend the logic behind Godots UI system. Main thing that makes no sense is the fact that if parent container has some values(like margin or position) set, then child node cannot override these values, effectively making child nodes parameters pointless and confusing.
Either remove the values that cant be changed, or make so that i can use them.

[Calinou]

@markotaht There's an open pull request that grays out non-changeable values and makes them non-editable, but it's blocked as the implementation needs a rework: godotengine/godot#30623

[markotaht]

While it will be an improvement. I kinda dissapointed in the choise. It will make creating the UI alot harder as the child has no power over itself.

[groud]

The child's properties that are used in a Container are the size flags and its min size. The anchors and margin values are useless in the container-based workflow.
It makes little sense to reuse the anchors and margins values in the container-based workflow, they are not the same thing. That's why preventing editing the margins and anchors when being a child of a container is the best solution so far.

[markotaht]

@groud Well i had a situation. Vertical layout, 4 elements. First element is gull height, the rest are half height. I cant set size to half since the container overrides it to full height. I had to do some black magic and sacrifice a goat to satan to get it working. It took my a good few hours to make it stop resizing the child and im still not sure why its working now. It would have been alot easier if i could have just said that margin from bottom 20 and then it internally can do whatever it wants, but externally the elements will stay half the height.

[groud]

It looks like your are too used to the HTML/CSS way of positioning the GUI elements. This is a complete different system from the one used by Godot, and it is unlikely we are going to change it.

The use case you describe is easily achievable by either nesting Containers, or by simply using no containers at all, positioning the elements using the anchors and margins workflow. This last workflow is probably the most recommended when you start having unusual layouts.
The documentation is probably lacking some information though, I have been working on a document explaining the GUI system better, but I still need some time to finish it.

[markotaht]

Better tutorials would be good. I guess i have to get use to this system. But could you do one thing. Could you implement draggable anchors. So that achors could be positioned by dragging them with the mouse.

Also, dont be so sure about not changeing the GUI system. Im more than sure that at some point down the line you guys are going to rework the GUI system completely.

[groud]

Dragging anchors is already possible, if you don't compile the master branch, you have to enable the helpers in the view menu. (they are always visible in the last version).

[girng]

While the container system itself is a good idea, the way to place and set elements is rather difficult. So Instead of parent container overriding the child node values

In my experience, 3.0 improved on the gui system a lot with the new layout system. In the editor, now UI creation is even more powerful and easier

While the container system itself is a good idea, the way to place and set elements is rather difficult. So Instead of parent container overriding the child node values, the child node values should be in reference to the parent container.

Not sure what the issue is here? That's what a container node is for, maybe you are looking for a new type of GUI node?

[Calinou]

Closing in favor of #2841, which is more likely to be adopted in the future (as this proposal lacks community support).