Best practices for executing edit-time code (and nuances specific to UI)?

Help
1

Godot Version

4.6

Question

I’m looking to populate some UI elements via script, where they are visible at edit-time for quick previewing/iteration.

Currently I am aware of @tool and Engine.is_editor_hint(), is it the only/best approach for this use-case?

Ideally I would like to keep the code limited to a single script while also having a way to more concretely isolate editor-only functionalities.

For example, instead of inserting runtime checks via Engine.is_editor_hint(), are there any useful editor-only signals, or ways to specify functions that should run (only?) during edit-time? So far I can’t find anything in the documentation beyond the initial solution.

Thanks in advance for any advice/assistance!

2

You may want to look into the EditorInterface class and read the plugin development guides:

You can recursively dump the interface of the gui using EditotInterface.get_base_control() to get a feel for the editor UI:

(This example is outdated, they renamed the AnimationPlayerEditor node, use the guide to actually hook into the editor unless there is no other way)

3

Ah sorry my post could have probably been worded better, I am not looking to extend the editor GUI, I am just looking to create/edit UI nodes via code at edit-time (as opposed to it occuring at runtime).

4

You can hook into the scene tree currently being edited using EditorInterface.get_edited_scene_root() as well.

5

The docs on running code on the editor say your editor scripts and @tool - ed scripts can fiddle around with the scene tree as opened in the editor:

image
image869×530 56.3 KB

However it also warns you that nodes added via script will not be saved to the scene’s file, unless you set their owner property:
image
image835×576 51 KB

6

Using Engine.is_editor_hint() you can make editor-only connections to signals. Similarly you can set_process(Engine.is_editor_hint()) to only run _process in editor. Point being you can diverge editor only code into certain functions which may help you reduce slapping a if Engine.is_editor_hint(): everywhere.

More concrete examples would help, what does your code look like right now? How do you want it to behave and how do you believe it is hard to achieve that?

7

Yes.

Sounds like the Manager Anti-Pattern, which is a bad idea.

No.

8

Thanks for the detailed answers everyone, I’m coming from Unreal where it already it has a solution for this via PreContstruct(), and so in some ways I was looking to replicate this behaviour:

{62AA68FE-CFC2-4CD0-8FAD-003D92B5058F}
{62AA68FE-CFC2-4CD0-8FAD-003D92B5058F}1053×337 42.1 KB

Similar behaviour is possible while still extending from Node, and @gertkeno’s mention of set_process() to disable _process at edit-time does help in isolating the editor-only functionality.

@tool
extends Node

func _ready() -> void:
	set_process(!Engine.is_editor_hint())

func _notification(what: int) -> void:
	if what == NOTIFICATION_EDITOR_PRE_SAVE:
		init_nodes()

func init_nodes():
	# create the node(s), setup attachment, optionally set owner for saving etc.

The class requiring @tool is still undesired

I am still quite new to Godot, and while writing this I realised I was probably coming at this from the wrong angle.

Since the UI is just a scene with Nodes I forgot that the local scene being edited can be played in isolation via F6. So I could also just do the node instantiation purely at runtime and preview the UI with F6.

Is the latter simply the “Godot way” to work with and preview UI created via code?

9

“UI added this way is transient and cannot be manually edited, but will still show visually in the designer” is that the main point? You want some small bit of this scene to function in editor as a preview?

I’m guessing F6 as mentioned is the best way to do that, test in-game as much as possible so you aren’t building tools and a game separately at the same time. If you only want to try your UI, then try it!

You can add a basic Node and give it your @tool script and any in-editor code. Generally it should function the same or close enough in load order as the first child.

10

I guess I was being a bit greedy with this post and trying to ask two questions, the first being generally how to approach editor-time functionality, and the latter being this, how I can quickly preview the code-generated UI in the editor for fast iteration, using said approach(es).

The generated Nodes/Scenes would be responding to some key vars that I would want to tweak a bunch and immediately see the outcome of, and I would say F6 is definitely good-enough, as it only takes a second or two to launch the local scene