Open piotrtrkostrzewski94 opened 3 weeks ago
I checked the Dockable Container code (https://godotengine.org/asset-library/asset/916) and noticed in the code line: extends Control, I combined this with the fact that e.g. Inspector allows changing its position with this extension so it means that UI elements that are built as Control are easier to change the position by the user. I have already added a PR to the extension with: extend EditorRun (file Godot/editor/editor_run.h), in my opinion it is also possible to solve this by changing the class EditorRun to Control. I will try to check the first option in my fork of Godot 3.6 on Friday, the second if I manage to change EditorRun to Control (probably more difficult)
Containers are better for positioning nodes, but you may need a custom one, with logic specifically for your task.
Yesterday I tried to add a new Dock to Godot but the first problem is that Godot does not display it despite setting a large icon.
Containers are better for positioning nodes, but you may need a custom one, with logic specifically for your task.
What is better in Container than using the above-mentioned solution?
Could someone check if this works? My commit: https://github.com/gilzoide/godot-dockable-container/commit/1f4d289065c4a343be6f8041a047bffd48ed47a4#diff-0eaeaa44151cb67b54a3275d396b747b6d782a3d2f7a2db5e898ec93aa02cf62 for https://github.com/gilzoide/godot-dockable-container, if so then we have a solution, I can check it on Friday
Update: Some problems with this change:
A script cannot extend 2 different classes, so this change actually breaks the project. EditorRun is an internal Godot class, it isn't registered in ClassDB, so it is actually not usable in GDScript.
UI elements that are built as Control are easier to change the position by the user.
Well yeah, but I think it's irrelevant for editor nodes. You can move nodes freely in your scene or via the inspector, but editor's controls are expected to be in a fixed place. Containers are better in that they have a predictable layout. When you resize a container, it will automatically sort its children to be where they should be, which you can't ensure with Controls. And predictable arrangement allows to define minimum size easier.
If you look at my video in https://github.com/godotengine/godot-proposals/discussions/12537#discussioncomment-13337093, the dragged elements are always aligned to the left. This is not easily possible with Control parent.
So theoretically I should change the class EditorRun to Container EditorRun, am I right? Container is not Dock, right?
Describe the project you are working on
A road transport simulator requiring a lot of testing.
Describe the problem or limitation you are having in your project
The hardcoded playtest buttons on the right are arranged for me opposite to my workflow.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
You can use (with possible changes if needed) code that allows you to move e.g. the Inspector to another place. Adding the ability to freely set the position of the playtest button will allow for a better workflow for people who want to have some UI elements in a different place (e.g. I want them on the left)
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
After "freeing" the playtest button, the user who wants to move UI elements will only need https://godotengine.org/asset-library/asset/916. The page shows how the extension works in combination with "unlocked" UI elements. It works on version 3.6 (I haven't tested newer ones)
If this enhancement will not be used often, can it be worked around with a few lines of script?
Since the UI elements are deeply integrated with the editor, I believe this cannot be done with an extension. The plus side is that some elements are already "unlocked", so you just need to "unlock" others and users who want to customize the UI will have an easier task.
Is there a reason why this should be core and not an add-on in the asset library?
It's too integrated with the editor.