Add margins and padding to Control nodes

[Shadowblitz16]

Describe the project you are working on:
Space ship game that requires gamepad and keyboard input.

Describe the problem or limitation you are having in your project:
I keep running into the problem where I have to modify my theme or style or having to create additional padding nodes to position controls within a container.

I have tried using things like margin containers but this doesn't always work and requires a extra node just to position the control

these things start to add up and in no time I have 3 layers of containers to get the flow, position, size and clip I need for only one control.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I suggest allowing us to specify a margin and padding for controls that is separate from its rect.

this allows us to make gui easier since we don't have to search through a bunch of container children

I would also suggest that like the anchor a padding and margin rect be added to the godot editor to ease of use.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
basically it would be similar to winforms but alot less buggy in which containers still position and resize their controls but users are allowed to adjust how they do it.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
this enhancement would be use alot more then the current system. while it allows for bypassing a bunch of nested container controls it they would also still be useful for alignment.

I don't think this can be worked around due to how containers position their controls but if it can be it would require quire a bit of knowledge about the godot engine and some people just want to make a gui.

Is there a reason why this should be core and not an add-on in the asset library?:
this would be added in the core because currently the gui system can be bit infuriating to work with

[aaronfranke]

This is possibly a duplicate of #728

[KoBeWi]

I have tried using things like margin containers but this doesn't always work and requires a extra node just to position the control

Well, working with UI requires lots of containers sometimes. The worst part is that smart snapping gets weird when you put too much on the scene, otherwise it's not really bad.
btw if you use PanelContainer, you can use content_margin property of StyleBox to replace MarginContainer.

[Shadowblitz16]

@KoBeWi
this requires a bunch of nested controls just to get something like a clipped border.

the point of this is so that we have somewhat of a way to organize our controls

@aaronfranke this is not the same thing as he is talking about merging containers and controls while I am talking about allowing us to specify a margin and a border between containers and the control.

currently the margin container doesn't even work it this way since its position and margin are tied to each other and the parent container resizes the position and size

[groud]

currently the margin container doesn't even work it this way since its position and margin are tied to each other and the parent container resizes the position and size

The margins of a MarginContainer are defined as custom constants, they have nothing to do with the basic Control's margins. This is basically stated in the documentation: https://docs.godotengine.org/en/stable/classes/class_margincontainer.html

That being said, I agree the naming is a little bit confusing. That's why I wanted, at some point, to rename the Control's margins properties to "offset_left", "offset_right" and so on. So that people stop understanding them as they were like CSS margins.

[Shadowblitz16]

@groud shouldn't the offset be ignored by the parent container then.

the point I am trying to make is its not very easy if at all possible to offset position and size of a control in a container.

every other gui library out there lets you do this.
the only extra part of this suggestion is to allow people to set a padding as well.

[groud]

@groud shouldn't the offset be ignored by the parent container then.

It should yes. It's just that visually in the editor those values get updated while they should not. That's why editing those values should not be possible.

the point I am trying to make is its not very easy if at all possible to offset position and size of a control in a container.

They aren't meant for it. If you need precise control on the positioning, you need to use a normal control as a parent instead of a container. The margins and anchors system allow you more custom positioning. And if the problem is only about the margins around the Control, then a MarginContainer works perfectly.

every other gui library out there lets you do this.

Could you provide examples ? I am not sure a lot of libraries allow you to specify a padding for each Control/Container node, but I might be wrong.

[Shadowblitz16]

• winforms
• wpf
• any sort of wpf like library
• css

@groud shouldn't the offset be ignored by the parent container then.

It should yes. It's just that visually in the editor those values get updated while they should not. That's why editing those values should not be possible.

they don't just get updated. position and margin are synced and margin isn't really a margin its a offset like you said

the point I am trying to make is its not very easy if at all possible to offset position and size of a control in a container.

They aren't meant for it. If you need precise control on the positioning, you need to use a normal control as a parent instead of a container. The margins and anchors system allow you more custom positioning. And if the problem is only about the margins around the Control, then a MarginContainer works perfectly.

no containers are for layouts
controls should be positioned by these layouts but should also have say in the amount of spacing around them.

every other gui library out there lets you do this.

Could you provide examples ? I am not sure a lot of libraries allow you to specify a padding for
each Control/Container node, but I might be wrong.

winforms
wpf
any sort of wpf like ui
css

you should really read up on the importance of margins and padding in ui.
I feel you don't understand what they are and how they help

[groud]

they don't just get updated. position and margin are synced and margin isn't really a margin its a offset like you said

What I meant by that is that, as soon as you resize the parent Container, the position, size, margins and anchors properties are going to be overridden. They are consequently not reliable and should not be updated (or synced, as you wish), when modified in the editor. They should not be editable at all.

no containers are for layouts
controls should be positioned by these layouts but should also have say in the amount of spacing around them.

No, that's not how Godot works. Once again, you want the engine adapt to your vision of things, but this spacing can completely be handled by a MarginContainer, as I said above.

you should really read up on the importance of margins and padding in ui.
I feel you don't understand what they are and how they help

I already know what they are and I they work, but, once again, you did not provide any use case for them which are not already covered by another solution in the engine (you can use MarginContainer or even a normal control node in the hierarchy to achieve the same result).

The only problem it could have with it is that it adds another node in your hierarchy, but honestly, I don't think it is a problem personally, as GUI layouts will always be complex anyway.

If we absolutely want to replace this intermediate MarginContainer by properties, I fear this will confuse users even more as they are going to be yet another set of Margins-like properties. This padding/margin will be used only inside containers as they can't be mixed with the current margins (or offset if we rename them), as those can be negative too, unlike padding. In the end, you node's position could be influenced by:

• anchors,
• margins,
• position,
• size,
• you new padding property

IMHO, the properties system is already complex enough, there is no need to complexify it even more.

[aaronfranke]

@Shadowblitz16 I would like to point out that you have the option to implement your own UI system in user code, using Godot's existing nodes as a base. You could create this as a proof-of-concept that people can try, or you can maintain it and publish it on the asset library.

[Shadowblitz16]

they don't just get updated. position and margin are synced and margin isn't really a margin its a offset like you said

What I meant by that is that, as soon as you resize the parent Container, the position, size, margins and anchors properties are going to be overridden. They are consequently not reliable and should not be updated (or synced, as you wish), when modified in the editor. They should not be editable at all.

then this should be considered a bug if they are not stable enough to expose to the inspector. and in that case the gui system should be rewritten

no containers are for layouts
controls should be positioned by these layouts but should also have say in the amount of spacing around them.

No, that's not how Godot works. Once again, you want the engine adapt to your vision of things, but this spacing can completely be handled by a MarginContainer, as I said above.

godot doesn't work like that because its not implemented yet.
my vision is to make godot easier to use.
and we shouldn't have to add 50 margin container's just because we want to have a offset from the parent container.

also I have said this already margin containers don't even work for things like tab containers since the tab container resizes the margin container making the margin container useless.
I have already posted this issue which YOU closed that had a example project godotengine/godot#38576

you should really read up on the importance of margins and padding in ui.
I feel you don't understand what they are and how they help

I already know what they are and I they work, but, once again, you did not provide any use case for them which are not already covered by another solution in the engine (you can use MarginContainer or even a normal control node in the hierarchy to achieve the same result).

The only problem it could have with it is that it adds another node in your hierarchy, but honestly, I don't think it is a problem personally, as GUI layouts will always be complex anyway.

If we absolutely want to replace this intermediate MarginContainer by properties, I fear this will confuse users even more as they are going to be yet another set of Margins-like properties. This padding/margin will be used only inside containers as they can't be mixed with the current margins (or offset if we rename them), as those can be negative too, unlike padding. In the end, you node's position could be influenced by:

• anchors,
• margins,
• position,
• size,
• you new padding property

IMHO, the properties system is already complex enough, there is no need to complexify it even more.

I provided at least 2 reasons why this would make the gui system better why don't you reread this suggestion.

I don't see how you don't think padding is a good thing to add to controls.
by your logic why do we even have anchors and margins if they can just be another node.
controls could simply just be a position and size but they aren't because it would again generate too many node to do anything.

this isn't any more complex then any other gui system.
they all have..

• anchors
• padding
• margins
• a rect
• some even have a border which is a one extra thing

@Shadowblitz16 I would like to point out that you have the option to implement your own UI system in user code, using Godot's existing nodes as a base. You could create this as a proof-of-concept that people can try, or you can maintain it and publish it on the asset library.

I shouldn't have to implement basic gui features that should already be there.

[trommlbomml]

I can follow @Shadowblitz16 argumentation and I would like to add some of my point of view which are often needed - especially if you rely heavily on layouts. Of course you can solve it differently with godot, but this is such a fundamental concept I really would like to take into consideration of redesigning the already great UI solution.

I also would like to point out "make your own solution" sounds like there are arguing points which are good but are not taking into consideration as this would change the UI system to much that backard compatibility is really hard?

Padding for Button content

the text and the distance to the border of the button should easily set up using padding. Often it looks way better to have some horizontal and vertical space between text and border. Having a property for that would be fantastic.

Margins for any control improves usability to improve UI quality

The current margin seems not be a layout but a relative positioning concept. Margin is "normally" an additional spacing around the control, the godot margin seems to inset that - thats really weird when you come from anything else. It is a common use case to tightly pack the elements using layouters and then add margins to controls to make it look good - and it is a fast and reliable workflow: You can concentrate on layout - as you would expect from a layouter as the name says - and define the distances with margins in a separate step simply by modifying the controls margin. My approach is currently to add everywhere margin containers where it is needed, this takes a lot of time and I would be much faster using a typical margin system.

Technical side

The implementation should be simple and can be integrated in control base class by simply adding the margin during size calculation and remove it during rendering phase and the benefit would be the system is much clearer and nearer to what anybody knows from one of the most common techniques for styles and layouting: CSS.

Downsides

As already said: backwards compatibility? People who like the current system and are not willing to change their mind?

[Kiaazad]

I'm coming from a renpy/unity background as a GUI designer. I've heard lots of people praising Godot's versatile interface design tools, but as soon as I've started using it, I've found the way Godot handles interface cumbersome.

The biggest advantage of adding margins, alignment and padding directly to the containers and buttons is simplicity. This simplicity removes the barrier that stands in front of developers migrating from other platforms.
There's also an obvious benefit to mimicking other successful platforms: flattening the learning curve.
Unity is switching to CSS for it's interface design by introducing their "UI builder", and that move alone makes it the engine of choice for tons of web developers that might have an idea to build a game or app, growing their user base by a huge margin.

I don't know why people argue against improving the tools they're using. It's not like we're asking to remove those center, align or margin containers and break backwards compatibility, all we ask for is improving the rest of them to make it easier for the newcomers and not leaving them scratching their heads for something that was simple everywhere else.

[Calinou]

I don't know why people argue against improving the tools they're using. It's not like we're asking to remove those center, align or margin containers and break backwards compatibility, all we ask for is improving the rest of them to make it easier for the newcomers and not leaving them scratching their heads for something that was simple everywhere else.

Adding multiple ways to achieve the same thing is not necessarily a net upgrade in terms of usability. It can introduce choice paralysis while making it more difficult for maintainers to fix bugs in the GUI system.

[Kiaazad]

Adding multiple ways to achieve the same thing is not necessarily a net upgrade in terms of usability. It can introduce choice paralysis while making it more difficult for maintainers to fix bugs in the GUI system.

Adding multiple ways is the first step of letting the users decide which way they prefer, specially when one involves much less work. We can deprecate the one less popular to prevent the slim chance that somebody couldn't decide which one to use.
I should warn you about cult mentality when you do something a certain way and believe it's the best till you get used to the way things are and resist any change. It's not that hard to find an excuse to maintain the status quo if you are looking for it.
I would love to be an advocate for the Godot engine, but it had to shoot that arrow to my knee and send me searching fora solution to some problem that shouldn't exist in the first place. instead of pushing my clients to switch to Godot, I'm arguing on Github for something that's clearly bothering the users to the point that there are multiple issues submitted for it.
all I'm saying is: Give us the legs to walk on our own before preaching about the efficiency of wheels.

[groud]

That won't happen sorry. We won't maintain several systems if the use cases are the same, especially if the only reason to have another system is "for the sake of letting people have the choice". As @Calinou mentioned, the additional workload on contributors would not be worth.

However, you are still free to create a new GUI system via a plugin, maintain it, then make it used by a significant amount of people to proove us your solution is better than the current one. In such case we would consider integrating it, or even replacing the current implementation. But otherwise, this won't happen.

[Kiaazad]

I would do that if I was using Godot for long enough to know what goes where. But you can't expect that from a newcomer, and those experienced enough to do so, are already part of the no change necessary cult.
I'm sure you can see the flaw in in your otherwise perfectly reasonable suggestion.

[groud]

and those experienced enough to do so, are already part of the no change necessary cult.

Well, wouldn't say it's a cult... And I would even say it's actually the opposite, since we are asking for good rational reasons to change our system, while you're advocating for changes for the sake of it. You know, " you should look at the beam your own eye instead of the mote in ours." 😉

[Kiaazad]

I won't argue what is, and what isn't a cult mentality. Instead...
I'll suggest: instead of rejecting the idea, point out the people that are asking for the feature to the proper starting point to implement what they are asking for, perhaps as a plugin that you've suggested.
And since it's the issue that's frequently coming up, maybe assign an experienced developer to guide them.

[groud]

I'll suggest: instead of rejecting the idea, point out the people that are asking for the feature to the proper starting point to implement what they are asking for, perhaps as a plugin that you've suggested.
And since it's the issue that's frequently coming up, maybe assign an experienced developer to guide them.

I'd be happy to help working on a solution, if we identify where the problem is, and if it worth solving because everyone would agree it's a problem. Right now, the only problem I identified in this proposal is the fact that our system leads to big nested structures of nodes. For me, it's not a big problem, and so far, we don't have a lot of complains about it too. So consequently, there's little interest in experienced contributors working on a solution for this (directly or indirectly). Note that you are welcome to prove me wrong, if you gather a lot of people having a big problem with this situation, we may reconsider the importance of the problem.

You can have a look to our workflow, it explains how we select things to implement pretty well: https://docs.godotengine.org/en/latest/community/contributing/best_practices_for_engine_contributors.html

[KoBeWi]

And since it's the issue that's frequently coming up

Is it really that frequent? Only 3 people commented here that aren't Godot engine members and the OP has no upvotes. Personally I don't really recall this problem being mentioned elsewhere (although I don't follow every community channel much). I mean, it's not really apparent that this proposal has much support.

As for the implementation, doing it via plugin would probably involve writing new GUI system. It would be easier to make a PR and maybe distribute a custom build for interested people. All relevant code to implement this proposal should be inside control.cpp.

[trommlbomml]

I am also a bit astonished about how people argue against something which is well established solution in UI systems - like e.g. the anchor system. Furthermore this is an approval issue tracker and I think that's also a reason there are not so much upvotes?

@KoBeWi it is not frequent because people are told e.g. add a margin container, update the texture or simply increase the size, that's also what I think @Calinou means there are other ways to do it - which is I think not ideal or basic problems like making layouting simple.

I also think that a lot of UI designs in games are more based on mockups and not on layouts like you do for business applications, where you need way more flexibility than in a compared simple game UI.

I think a good Idea would be using a pull request, too. At least my intention was to produce some focus on this topic to make more people aware of this property.

[Kiaazad]

It's a case of "Abraham Wald and the Missing Bullet Holes". Most of those whom have this problem just give up and move unto another engine. The few that bother to submit an issue, really care about open source and the potential value that Godot can bring to their workflow.
In my case, I've already developed the rest of the game for my client, moving onto another engine means starting from scratch and I'm too lazy to give up that easily.
The only argument I keep hearing is: For me, it's not a big problem. In my opinion that is the wrong attitude towards those whom see it as a big problem and try to help correcting it.
I've pointed out several problems with the current system that you've already agree on at least one, but let me list them again in case I didn't get any of those points across:

1. The current system leads to big nested structures of nodes.
2. It's very unintuitive for those whom are migrating from other engines.
3. It's very unintuitive for those with a background in some of the most popular languages out there, (don't tell me 94% of the internet is wrong with their fancy CSS styles)
4. The learning curve is too steep.
5. We're losing new users to maintain the status quo.
6. My clients are not happy about the slow progress of their project (yes I'm counting that as a problem)

[Zireael07]

@KoBeWi: IIRC we had a similar issue back on the bug tracker and it had more support there.

The main reasoning in favor was familiarity for users of most engines out there (and yes, that includes CSS)

[bluenote10]

Most of those whom have this problem just give up and move unto another engine.

Fwiw, I also came with a CSS background, got confused by Godot's notion of margins, and had a similar initial impression as you. However after using it for a while the system started to make sense, and perhaps it is even superior to how CSS works.

[Calinou]

@bluenote10 Renaming margins to offsets might be enough to cure the confusion 🙂

Having done web development professionally, CSS is good and all, but supporting a CSS-like system within Godot is a lot of work and might end up confusing people as well (because it won't behave exactly like CSS in a browser would).

[trommlbomml]

I also hope CSS like support is not coming to Godot as a core features - it's hell in detail to layout everything good, other layout systems are way easier including Godot. But having the margin model and maybe call it different would be a good solution I think. Maybe we can refer for this not as offset but maybe spacing as it is indeed adding space around controls?

[Shadowblitz16]

the issue is not the naming its that there is no way to specify outer spacing
The containers resize their children which have no control over their size forcing the user to have a extra node for every container in the scene.

[KoBeWi]

forcing the user to have a extra node for every container in the scene.

Why exactly an extra node is a problem?

[YuriSizov]

I know what you mean, but this doesn't exist in Godot, because controls are not following the box model or anything similar. There is a different approach in Godot's UI system, and it works well.

We can talk about making styleboxes more obvious and easy to edit, but there is no reason to complicate things and split parts of it as virtual properties of control which cannot be used.

[Shadowblitz16]

@pycbouh is disagree its confusing, limited and has inconsistencies when it comes to the layout of parents and children.

[Kangrew]

I agree with @Shadowblitz16 , the naming is really confusing and I often get things mixed up. I get what @pycbouh is coming from but we have to change and come up with different names to that used in the css box model as it easily misleads someone with a web or similar background. I refused to use Godots container approach for a very long time because of this. And im talking about completely different names as that would at least make new users give the current system a chance or it creates a negative bias towards the current system from the get go.

[YuriSizov]

@Kangrew There is already a proposal to rename margins to paddings where appropriate.

[Kangrew]

@pycbouh I was suggesting something completely different to box model names. I think people new users will start expecting it to work like css.

[YuriSizov]

Those words are not exclusive to CSS and box model. We shouldn't go out of our way to distinguish from that, their meaning is pretty clear and used for various layout systems and just visual design in general.

[Kiaazad]

I'd say add margin, padding, align and offset to all container, and keep the container form of them the way they are for anybody whom like it that way.
It's clearly an issue bothering the newcomers and addressing it can't negatively effect the existing users in any way, just don't use them. The thing I'm baffled by is the amount of resistance towards this change.

[YuriSizov]

I'd say add margin, padding, align and offset to all container, and keep the container form of them the way they are for anybody whom like it that way.

You already have margins for controls and containers that can be positioned with margins. But there are other methods of positioning which do not involve those. See #2841 for a discussion on what modes of positioning are available, when they are applicable and how to make them more clear to the users.

Paddings is what MarginContainer is for, but I personally wouldn't mind it being a property rather than a node. I think having it as a separate node allows to simplify the drawing logic for every control, as it only needs to worry about its own rect size and nothing else. This can probably be solved by helper functions, but the change won't be easy and will have a cascading effect. Having a node isn't that bad anyway, but I agree with #2334 that it can be renamed to PaddingContainer, so that its properties are not confused with margins used for positioning.

There is no universal rule for alignment. Some containers do have alignment as their inherent property but that ties to their special behavior. Overall alignment strategy depends on which positioning mode is applicable, and can be related to anchors, grow directions or some container-specific behavior. Once again, see #2841.

I don't know what you mean by offset, because it's just a generic word and both margins and paddings are offsets.

It's clearly an issue bothering the newcomers

There is no universal truth to it. Yes, people coming from using a different UI system would need to learn this one. Like I've said, we can and should work on the presentation of data, but the mere fact that there is a different kind of system used for UI in Godot doesn't mean that it's a bad system. And the fact that it requires mastering doesn't mean it's unworthy of being mastered and needs to be replaced with some other run-of-the-mill approach.

addressing it can't negatively effect the existing users in any way, just don't use them

Most proposals regarding changing the way our system works are based on misunderstanding the system, its compromises and its patterns. And so they often ask for unrealistic "just add this for us, don't use it if you don't need it" when in reality those changes would cause great affect, or would introduce an unnecessary split in user-land approaches to solving problems.

I firmly believe that this is more of a UX problem than the underlying implementation problem. If Godot had, say, a UI designer tool, nobody would care for the internals which currently are exposed more or less as is. Same as nobody would suggest we move to the box model or implement CSS support if they new how awful those things are internally and how many hacks they require to function in a sensible way.

[Kiaazad]

I've seen those same arguments before. It's the resistance I'm talking about.

There is no universal truth to it.

I don't know what passes as a universal truth, but when people bother to come to github and complain, it means they have exhausted every other option they could try and their problem persists, reading the documentations, watching videos, searching google and asking on the forums. Now imagine how many gave up on the way.

There is no universal rule for alignment.

I don't think anybody would write a universal set of rules for something like this. usually a node can be aligned to some fraction of it's parent, on x and y axis, be it another node or the screen. it's not that complex, if there is extra room, the node can be on one of the sides or somewhere in between. We can just look at how others do it and learn from them.

Most proposals regarding changing the way our system works are based on misunderstanding the system.

If the system causes lots of misunderstanding, maybe there's something wrong with the system.

Even if none of suggested solutions where valid, the fact that there's a discussion on the topic means there's a problem. You can't argue away the source of people's dissatisfaction with the status quo. It's not the problem that goes away with these arguments, it's the people.
I, as a sample of one, decided to migrate to godot years ago, got into problem with the interface design tools, spent doing all of the aforementioned steps. gave up several times, last year decided to try harder, landed on github discussions and got chased away by the same arguments that I'm still hearing. I know the next arguments would be along the lines: godot is open source, do it yourself. well... I would if it was my area of expertise. I can offer my years of experience in UI/UX design instead. All I'm asking in return is to be heard.

[YuriSizov]

I don't know what passes as a universal truth, but when people bother to come to github and complain, it means they have exhausted every other option they could try and their problem persists, reading the documentations, watching videos, searching google and asking on the forums. Now imagine how many gave up on the way.

And when they don't have a problem they don't come to GitHub and don't express how it just clicks with them or how they've mastered it after a while. This metric is not representative, it's a vocal minority bias.

Usually a node can be aligned to some fraction of it's parent, on x and y axis, be it another node or the screen.

If you don't ignore the rest of my explanation, you will learn that the "universal rule" was in relation to different types of containers. You ask us to put some "align" property on the base container. This is impossible, because there is no one way of alignment implemented — this is what different ways of positioning and different types of containers are for. If you want to just align controls against other controls, you may not need containers at all; that's what anchors are for.

If the system causes lots of misunderstanding, maybe there's something wrong with the system.

You see resistance, and I see baseless generalizations about "lots of" problems. Like I've said before, for every report from people misunderstanding the system there is a person who doesn't and therefore doesn't report anything to GitHub. You say you come back years later and see the same arguments used against you. Maybe that's people who get the system and they are trying to tell you that they exist and try to make you hear them out as well.

Even if none of suggested solutions where valid, the fact that there's a discussion on the topic means there's a problem. You can't argue away the source of people's dissatisfaction with the status quo. It's not the problem that goes away with these arguments, it's the people.

And I don't deny there is a problem, look at my closing paragraph:

I firmly believe that this is more of a UX problem than the underlying implementation problem.

[Kiaazad]

If others have done it and got better results, with less frustration for the users, maybe godot's approach isn't that optimal.
I don't see that many people having trouble with the interface tools that some of much smaller engines provide. It can't be the users either since I've tried many engines and only godot gave me this much grief. but neither are the main problem. THe main problem is the answers.
Many users come and suggest things with good intention, they see something missing or something that can be improved and mention it because they like everything else about the engine, but all they find is a wall in front of their face telling them no.

[YuriSizov]

You seem to be frustrated and ignore a significant chunk of what is being explained here. I'm sorry that you've ended up feeling ignored, but please keep in mind that even when some of the maintainers tells "No" to your idea they also come with good intentions but probably a different outlook on the problem. Rejections is a part of any proposal discussion, please don't take it personally.

[Kiaazad]

It's more the reasons given are the thing that bother me than the rejections. Just because some of the users got used to the current system, all new users that have a difficult time with it are rejected. it's like comparing godot to other engines is a sin and forbidden.

[Killfrra]

I would suggest not to invent your own UI system, and instead, change how the current system is represented to the user.
I started writing a plugin for Godot 3.3 in GDScript, which would solve this issue and #728 as well, but faced with difficulties. It would be much easier if you could inherit, for example, from SceneTreeEditor, override its methods and have access to its variables, as it would be with a node written on GDScript. But since there is no such possibility, I had to do with frank hacking: to rebuild the Tree, intercept signals, temporarily push data to where it will later be read by the function, determine the TreeItem's button id by Texture... Still couldn't get CanvasEditor and Inspector to edit different nodes at the same time. Perhaps some of the problems are solved through the writing of the module in C++, but I am worried that the potential user will have to compile it. It seems to me that the lightweight engine that tries as much as possible the functional to be taken into plugins should be easier in the extension. But in any case, it is cool that the engine is built on the same basics as the games in it. If anyone wants to help with the writing or to see what I've done, you are welcome to my repo

[Kiaazad]

I would suggest allowing the users to design their interface in another tool, add it to the game in something like uxml and show it on top like how the new unity does it.
Clean and modular. No need to touch the existing system either, just hook it into the engine and let the users decide, although, knowing the community I'm sure somebody will find something severely wrong with this idea and shoots it down in one swift excuse.

[YuriSizov]

@Kiaazad You are completely free to make such a tool and integrate it with Godot's UI system. Nobody can shoot it down if that's what you want to do.

[Kiaazad]

@Kiaazad You are completely free to make such a tool and integrate it with Godot's UI system. Nobody can shoot it down if that's what you want to do.

Ah, the "Godot is open source, do it yourself!" excuse right out of the bat.
Don't you think if I could, I would've already done it instead of coming here suggesting it?
Unfortunately as a new user, there is a big barrier in front of me, that is Godots interface tools, it's clunky and unintuitive, making it unbearable to learn.
first let people in then except them do these kind of things.

[YuriSizov]

If you were proposing we create a dedicated tool that implements a separate, contesting system for the one we already have as a core project, like Unity does for a lot of its technologies, this will not happen. We have a limited amount people as it is, not enough to support two contesting stacks.

It was stated many times before that we are open to making UX changes to make the process of learning Godot's UI system more straightforward. There are in fact a number of proposals and PRs targeting that.

As for calling it an "excuse", well, as an open source project we live and die with our community and our contributors. This is the matter of fact when picking Godot over something else, and it may not be for everyone. Many regular contributors work voluntarily and paid contributors are numbered. So indeed, if there is a need in community to design a completely new process for UI because for some learning Godot's system is a complicated task, it would be in the interest of the said community to start some work on it. Good work may end up in the engine and help lots of people, niche work can still help those who need it without overburdening the core engine.

[Kiaazad]

We have a limited amount people as it is

I can guess why that is the case, I personally love Godot, sans it's interface tools of course, and as an experienced UI designer I offered to help improving it but I was denied at every door.
The amount I can contribute might be small to begin with, but you can't complain about not having enough people while closing your doors on everybody's face.
It's been a year or more since we have pointed out the problems with the interface nodes and suggested ways to remedy the situation, the best thing we got in return was being ignored if not denial of the said problems or refusing to listen to our reason.
Again, I'm extending my helping hand to anybody whom is interested in using my experience as a UI designer to improve the user experience when it comes to using the interface tools. I can't code but I can point out where it can be improved and how.
Let's watch it getting slapped away yet another time.

[Zireael07]

"It's been a year or more since we have pointed out the problems with the interface nodes and suggested ways to remedy the situation, the best thing we got in return was being ignored if not denial of the said problems or refusing to listen to our reason."

I don't see many thumbs-up on the proposal and I only see what, three people in favor of it in this proposal thread.
No one is refusing to listen to your reasons (this proposal is still open) but I simply don't see as much of a support for this as you seem to think there is (see this nice website https://godot-proposals-viewer.github.io/ displaying proposals in a rough popularity order).

Most proposals, especially very complex ones, get done because there's clear, overwhelming support for them AND there is a contributor on hand who can do it. Again, just by glancing at the list linked, there are many proposals with overwhelming support that haven't happened yet because of the limited amount of contributors...

[YuriSizov]

This was not a complaint, it is the reality of the situation. Same with issues taking long time to resolve sometimes. It is what it is.

I don't know who've closed the door in your face many times before but the entire time you and I are discussing things here you have been extremely negative towards everything said to you and very dismissive of what Godot is and what the arguments against your points are. This attitude doesn't help others to hear you out. It's clear that you don't like what is being explained here, but pointless bickering doesn't move the discussion forward.

I've already extended my regards about the way you feel you were treated before, but I can't do it every time you revive this thread to curse the developers for not seeing things the way you do.

[YuriSizov]

And by the way, we have this discussion on a proposal that has exactly one vote in favor. After a year of being open it can be closed at this point as not desired by the community.

Edit: Oops, missed Zireael's comment about the same.

[Kiaazad]

Ouch... one slap was enough...
First: I'm not reviving this issue, every now and then I get an email notification that somebody commented on it and since not much have changed since the last time, I chip in with my disappointment. And I don't remember cursing.

Second: #2841 is basically pointing to this same issue of the interface tools being unintuitive, and it's one of the top issues on the nice page that Zireael07 presented. I'm sure there are many issues posted on something related to this that don't get that much attention like this one, but it doesn't mean none of them are valid.

Third: nobody cared enough to point us to the popular ones so we can support them to be done, that's another way people get ignored.

And finally: Thank you for letting me know how much my concern and offers (bickering) means to the community and the fact that they are pointless.

[Zireael07]

#2841, though, has much more support (even though people are clearly divided on it, with almost as many downvotes as upvotes) than this one has, probably because it doesn't involve a complete redesign of how Godot's UI nodes work (and therefore is much more likely to happen). This one feels like trying to shoehorn Godot into how CSS works (and CSS is known to have many faults and unintuitive quirks - I am a web dev by day)

BTW I can see why #812 (comment) feels like "bickering", but I don't see any "cursing"

I'm not reviving this issue, every now and then I get an email notification that somebody commented on it and since not much have changed since the last time, I chip in with my disappointment.

This is literally what @pycbouh means - you keep reviving the issue every time you "chip in with your disappointment". This is not very constructive since the Godot team has already seen your previous comments, they know what you don't like about the current situation

[KoBeWi]

btw if you don't like email notifications, you can unsubscribe from the issue.

[YuriSizov]

Coincidentally #2841 was the exact issue I mentioned in my first comment to you, Kiaazad, here a month ago, as an example of us working on UX rather than redesigning the whole UI system.

In fact, let's close this one as not getting traction and lacking constructive discussion in favor of #2841.

[trommlbomml]

Sorry for answering a closed issue, but I also was one of the answering people having a great interest and stopped discussing because it seems like the core team does not seem to see the benefit - or I did not follow every answer, sorry.

I don't see many thumbs-up on the proposal and I only see what, three people in favor of it in this proposal thread.
No one is refusing to listen to your reasons (this proposal is still open) but I simply don't see as much of a support for this as you seem to think there is (see this nice website https://godot-proposals-viewer.github.io/ displaying proposals in a rough popularity order).

Not many people (also me) know, that these thumbs are the indicator to push this feature to a priority. I think having so many comments in this thread is also an indicator, isn't it? A lot of people even do not write or thumb up but agree on many features but want to have them, so I think you make it yourself a little bit too easy. I also look at many features and I think they make sense, but do not vote or add a thumb up.

Most proposals, especially very complex ones, get done because there's clear, overwhelming support for them AND there is a contributor on hand who can do it. Again, just by glancing at the list linked, there are many proposals with overwhelming support that haven't happened yet because of the limited amount of contributors...

I understand that there is no high priority because you can workaround it easy sure and there are more important things. The main discussion was that the "margin concept" is kind of standard in multiple ui frameworks and is such a well-known feature seems to be for me like a great addition, but it is refused to be implemented in general.

[YuriSizov]

Not many people (also me) know, that these thumbs are the indicator to push this feature to a priority.

Thumb ups and thumb downs are the indicator for user support, not for priority. Comments can also indicate support, but we don't allow empty comments that don't add anything to the discussion, and the comments that do add to the discussion cannot always be evaluated as easily as a reaction on the OP. With all that said, most popular proposals don't have any issue getting thumbs on them, so even if some people miss that mechanic, it's not the majority.

We can of course explain it better in the README.

I think having so many comments in this thread is also an indicator, isn't it?

As Zireael mentioned, most comments were made by the same couple of people, so no, unfortunately it's not really indicative of anything.

A lot of people even do not write or thumb up but agree on many features but want to have them, so I think you make it yourself a little bit too easy. I also look at many features and I think they make sense, but do not vote or add a thumb up.

Getting a popular vote is one of the main points of this repository. There are no hard rules that you need to get X number of votes for a feature to be implemented (it can be less, or it can be declined even if there is a hundred of upvotes). But the OP is still required to demonstrate the popularity. If they can do it in any other way (show a Reddit thread with a lot of upvotes for example) they can refer to it as well. But lacking any other means, user votes are what shows if there is or isn't any interest, ultimately.

If you feel like the whole process is not properly explained, feel free to open a meta proposal/a PR against this repo to amend that.

The main discussion was that the "margin concept" is kind of standard in multiple ui frameworks and is such a well-known feature seems to be for me like a great addition, but it is refused to be implemented in general.

Once again, there are margins in Controls, several different ones in fact, depending on what you need. You have margin positioning, you have MarginContainer for insetting and styleboxes have content and expand margins for adjusting the visual positioning of control's content.

What is refused here is to implement a new independent system to replace Godot's UI system, or to work in parallel with it. We don't see the point in it, but we do see the point in making the UX of working on controls better. The lack of discoverability is not the same as the lack of features. And "just add HTML + CSS", like so many similar ideas are expressed, is not the solution.