Add CanvasItemEditor and SpatialEditor to the docs for EditorPlugins usage

[WhalesState]

Describe the project you are working on

an Editor plugin to clean the UI and to save me time while working

# things like packing all the select modes in one options button so the toolbar becomes cleaner

# and this is before

Describe the problem or limitation you are having in your project

while making a plugin, we will need it for sure, the only way to access those classes properties and methods are from the ClassDB , please add those Classes to docs and list their methods, even if with no details, it would be amazing if we can have them as a type in Godot like var cie: CanvasItemEditor = get_canvas_item_editor() later i can list all the properties and methods from ClassDB and i will add them in a comment here with some details as much as i can, thanks in advance.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

i can't use those classes as a type and it's so hard to know their constants and how to use each method.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

here's an example for the CanvasItemEditor methods list

i will be updating each method info and constants in my free time for anyone who needs it

var canvas_item_editor_method_list_name = [
    "_button_zoom_minus",
    "_button_zoom_reset",
    "_button_zoom_plus",
    "_button_toggle_smart_snap",
    "_button_toggle_grid_snap",
    "_button_override_camera",
    "_update_override_camera_button",
    "_button_toggle_anchor_mode",
    "_update_scroll",
    "_update_scrollbars",
    "_popup_callback",
    "_get_editor_data",
    "_button_tool_select",
    "_keying_changed",
    "_unhandled_key_input",
    "_draw_viewport",
    "_gui_input_viewport",
    "_snap_changed",
    "_queue_update_bone_list",
    "_update_bone_list",
    "_tree_changed",
    "_selection_changed",
    "_popup_warning_depop",
    "_add_node_pressed",
    "_node_created",
    "_reset_create_position",
    "_selection_result_pressed",
    "_selection_menu_hide",
    "get_state",
    "set_state",
    "update_viewport",
    "_zoom_on_position",
]

# and this is the code to expose them

func _ready() -> void:
    var db := ClassDB
    var cie = db.class_get_method_list("CanvasItemEditor", true)
    for i in cie:
        print(i["name"])

If this enhancement will not be used often, can it be worked around with a few lines of script?

for Plugins Creators who wants to access the 2d and the 3d editors then surely yes

Is there a reason why this should be core and not an add-on in the asset library?

because we will use it while making the plugins themselves and there's no docs or auto-completion and even we cant use them as type-hints in gdscript

[YuriSizov]

Those classes are not in the docs because they are not exposed for scripting. The fact that you can find their methods in the ClassDB is a side-effect of how 3.x works internally, and is no longer the case in 4.0 where those methods are used internally without being bound by ClassDB.

You should not rely on those methods, they are not guaranteed to preserve any compatibility even between minor and patch releases. And for the same reason, internal classes are not documented.

[WhalesState]

@pycbouh is there's any plan to add CanvasItemEditorPlugin and SpatialEditorPlugin in the future to allow us to access the 2D/3D editors ?

[YuriSizov]

@pycbouh is there's any plan to add CanvasItemEditorPlugin and SpatialEditorPlugin in the future to allow us to access the 2D/3D editors ?

You can already access the parts that we open for customization. You have methods to draw over the viewports, and to capture mouse events, and you have methods to add toolbars and sidebars.

Methods to remove existing toolbars are unlikely to be on the table for plugin API, as that is a rather niche problem. We prefer to keep editor API slick and impacting the majority of users, for better or worse. The reality is that opening up parts of the editor seems fine on paper, but it's additional maintenance cost and obligation to keep compatibility for. It restricts what we can do internally, as we have to consider public usages instead. Overall, not worth it for niche problems. But your example can still be solved by tree wrangling. At least, for now.