Expose CreateDialog by adding EditorCreateDialog singleton (accessed via EditorInterface).

[Lazy-Rabbit-2001]

Closes: godotengine/godot-proposals#11238 (Will be done via an addon if this gets merged)

Exposes CreateDialog in another way: By adding a new class EditorCreateDialog as a singleton that can only be accessed via EditorInterface, with some singals and methods.

Signals

created: Emitted when an objects is created from the create dialog.
favourites_updated: Emitted when the content of "favourites" slot gets updated.

Methods

add_type_to_blacklist(type_name: StringName): Adds a type to the blacklist and update the search result of the create dialog. The type in the blacklist will not be displayed in the create dialog.
remove_type_from_blacklist(type_name: StringName): Removes a type from the blacklist. The type removed from the blacklist will get recovery of being displayed in the create dialog.
set_type_custom_suffix(type_name: StringName, custom_suffix: String): Sets the custom suffix of the type in the create dialog. The item will display its suffix with higher priority. If the custom suffix is an empty string, the suffix will be hidden. This is useful for labeling the node by someone, or from some addon, or being used as a "namespace".
get_type_custom_suffix(type_name: StringName): Returns the custom suffix of the type in the create dialog.
clear_all_type_custom_suffixes(): Removes all custom suffixes in the create dialog from all types (If the type is a script type, then it will fall back to showing the file name of the script).
get_search_options: Returns the "result list" (Tree) that is used in the create dialog.
get_dialog_window: Returns the create dialog window. (ConfirmationDialog)

Why not exposing CreateDialog

Exposing CreateDialog seems to be a much more easier and direct way. However, when a user is trying instantiating it with new() by mistake, the whole engine will crash. To make users' engines safe, EditorCreateDialog provides a safer box where users will receive an error if they are trying to instantiate an EditorCreateDialog without passing in a CreateDialog instance, which is not exposed to the engine, and the instance create by mistake will be deleted immediately. A user should never try instantiating EditorCreateDialog, even though it's safe for them.

Getting the instance of EditorCreateDialog

A user can get access to it by calling EditorInterface.get_create_dialog().

WIPs

• Adding basic interfaces.
• Basic bug fixes and docs, (done 50%)
• Further fixes, local and inter-member tests.

[KoBeWi]

Can't the dialog be exposed via a method, like we did with SceneTreeDialog (popup_node_selector()) etc?

[Lazy-Rabbit-2001]

Can't the dialog be exposed via a method, like we did with SceneTreeDialog (popup_node_selector()) etc?

It can, but i forgot to update this in the top post. I'll update it soon.
However, what you get is its base type ConfirmationDialog, not CreateDialog.

[KoBeWi]

That doesn't really answer my question.
It can be implemented as popup_create_dialog(callback, base_type, type_blacklist, type_custom_suffix) (arguments up to discussion) instead of exposing a whole class. Though looks like you are also adding some new functionality.

[Lazy-Rabbit-2001]

That doesn't really answer my question. It can be implemented as popup_create_dialog(callback, base_type, type_blacklist, type_custom_suffix) (arguments up to discussion) instead of exposing a whole class. Though looks like you are also adding some new functionality.

This is good for addons that needs a custom create dialog, but for those who needs native changes, I mean, for tweaks on the native create dialogs, singleton is still the best solution from my own perspective of experience.
I'll consider add a popup_create_dialog() for EditorCreateDialog singleton.

[KoBeWi]

but for those who needs native changes, I mean, for tweaks on the native create dialogs

Like what tweaks? The current properties can be replaced by arguments, like in my example.
I see you have getters for some internal parts of the dialog, but are they useful? (and for what?)

[Lazy-Rabbit-2001]

but for those who needs native changes, I mean, for tweaks on the native create dialogs

Like what tweaks? The current properties can be replaced by arguments, like in my example. I see you have getters for some internal parts of the dialog, but are they useful? (and for what?)

Or I can say, to "override" the native create dialogs.
E.g. when you click on the "+" at the top left of the scene tree editor to add a node, you want to "override" the native create dialog with your custom one.

[Lazy-Rabbit-2001]

A fresh idea just hit me. Well, the next push will come soon.

[Lazy-Rabbit-2001]

Superseded by #100135