# Godot EditorNode Architecture: How the Editor Integrates with the Engine > Explore the Godot EditorNode architecture Understand how this singleton node integrates the editor with engine subsystems manages UI and plugins for a seamless editing experience. - Repository: [Godot Engine/godot](https://github.com/godotengine/godot) - Tags: architecture - Published: 2026-02-26 --- **EditorNode is a singleton Node-derived class defined in [`editor/editor_node.h`](https://github.com/godotengine/godot/blob/main/editor/editor_node.h) that instantiates the Godot editor as a regular scene-tree node, enabling direct access to engine subsystems while managing the entire UI hierarchy, plugin ecosystem, and editing lifecycle.** The godotengine/godot repository implements the Godot editor not as a standalone application, but as a specialized scene tree that runs inside the same runtime as your game. Understanding the EditorNode architecture reveals how this central singleton bridges the visual editing interface with core engine services like rendering, input, and resource management. ## What Is EditorNode? EditorNode is the central controller class declared in [`editor/editor_node.h`](https://github.com/godotengine/godot/blob/main/editor/editor_node.h) and implemented in [`editor/editor_node.cpp`](https://github.com/godotengine/godot/blob/main/editor/editor_node.cpp). As a subclass of `Node`, it participates in the standard scene tree lifecycle while serving as the root container for all editor functionality, from the main menu bar to the 2D/3D viewports. The class implements the singleton pattern through a static pointer `EditorNode *singleton` defined at line 205 of [`editor_node.cpp`](https://github.com/godotengine/godot/blob/main/editor_node.cpp). Global access is provided via `EditorNode::get_singleton()`, declared at line 44 of the header file. This design ensures that only one editor instance exists per process, with global accessibility for both internal systems and plugin development. ## Core Responsibilities of the EditorNode Singleton ### Singleton Access and Global State EditorNode maintains global state through the static `singleton` pointer set during initialization. When the editor launches (specifically in [`main/main.cpp`](https://github.com/godotengine/godot/blob/main/main/main.cpp) for the Editor build target), this singleton becomes the authoritative source for editor-wide operations, providing thread-safe access to the UI, settings, and engine configurations. ### UI Hierarchy Management EditorNode owns references to every top-level UI control forming the editor interface. The header file (lines 35-86) declares critical members including: - `MenuBar *main_menu_bar` – The top application menu - `DockSplitContainer *center_split` – The central split container managing dock layouts - `EditorSceneTabs *scene_tabs` – The scene tab bar These controls are standard Godot `Control` nodes parented under `gui_base`, allowing them to render through the same viewport system as the game scenes being edited. ### Editor Data and State Persistence The singleton owns and manages several data objects that persist across editing sessions: - `EditorData editor_data` – Tracks opened scenes, scene tabs, and active editors - `EditorFolding editor_folding` – Stores resource folding states in the FileSystem dock - `EditorSelectionHistory editor_history` – Maintains navigation history for the "Go Back" functionality ### Plugin System Orchestration EditorNode manages the complete lifecycle of `EditorPlugin` instances through `Vector editor_plugins`. It maintains fast lookup tables via `HashMap addon_name_to_plugin`, enabling efficient activation and deactivation of extensions written in GDScript, C#, or C++. ### Engine Services Integration Through methods like `_update_from_settings()` and the `_notification()` callback, EditorNode makes direct calls into `RenderingServer`, `DisplayServer`, `OS`, and `Engine` singletons. This architecture enables real-time synchronization; when you change VSync settings or rendering backends in Project Settings, `EditorNode::_update_vsync_mode()` and related methods propagate these changes immediately to the engine. ## EditorNode Lifecycle and Notifications The EditorNode architecture leverages Godot's notification system to initialize and maintain the editing environment: ### NOTIFICATION_ENTER_TREE Sets `Engine::editor_hint` to true, disables node threading for editor stability, connects UI signals, initiates the first `EditorFileSystem` scan, and registers the singleton pointer (`singleton = this`). This establishes the editor's presence within the running engine. ### NOTIFICATION_READY Finalizes UI layout through the dock manager, applies the editor theme via `_update_theme()`, and starts background timers for file system monitoring and import processing. ### NOTIFICATION_PROCESS Handles per-frame updates including selection refresh in the inspector, import progress monitoring, spinner animation, and auto-save triggers. This callback ensures the editor remains responsive while background tasks execute. ### NOTIFICATION_EXIT_TREE Performs cleanup by saving editor state to disk, destroying UI objects, unregistering plugins, and clearing the singleton pointer to prevent dangling references during shutdown. ## How EditorNode Integrates with the Engine ### Scene Tree Participation Unlike external editors that communicate via IPC, Godot's EditorNode adds its root control (`gui_base`) as a child of the main viewport. All editor chrome—the menus, docks, and panels—are regular `Control` nodes rendered by the same `Viewport` that displays the 2D or 3D scene under edit. This architectural choice eliminates context switching and enables seamless picking and manipulation of scene objects. ### Settings Synchronization EditorNode utilizes `GLOBAL_GET` and `EDITOR_GET` macros coupled with direct server calls to reflect project settings changes instantly. The method `_update_from_settings()` (called when project settings change) updates the rendering method, HDR mode, and VSync state by calling into `RenderingServer` and `DisplayServer` immediately, without requiring an editor restart. ### Input Handling and Shortcuts The `EditorNode::shortcut_input()` method (implemented at lines 6-49 of [`editor_node.cpp`](https://github.com/godotengine/godot/blob/main/editor_node.cpp)) intercepts input events before they reach the edited game scene. This prioritization allows the editor to consume global shortcuts (like **Ctrl+S** for save or **F5** for play) while preventing them from affecting the running game preview during scene testing. ### Resource System Integration EditorNode utilizes `ResourceLoader`, `ResourceSaver`, and `ResourceImporter` directly for asset management. It tracks resource usage per scene through hash maps like `resource_count`, enabling intelligent dependency tracking, automatic reimporting when source files change, and thumbnail generation for the FileSystem dock. ## EditorInterface as the Public Bridge While EditorNode contains the implementation details, `EditorInterface` (defined in [`editor/editor_interface.h`](https://github.com/godotengine/godot/blob/main/editor/editor_interface.h)) provides the stable public API exposed to GDScript and C#. This wrapper forwards calls to the EditorNode singleton: - `EditorInterface::get_editor_settings()` delegates to `EditorNode::editor_settings_dialog` (line 108) - `EditorInterface::get_base_control()` returns the root `Control` owned by `EditorNode::gui_base` (line 122) - `EditorInterface::edit_node()` triggers the inspector update workflow via the singleton This abstraction layer maintains binary compatibility across Godot versions while allowing plugins to interact with editor internals safely. ## Practical Implementation Examples ### Accessing EditorNode from a GDScript Plugin ```gdscript # my_plugin.gd extends EditorPlugin func _enter_tree(): var editor = EditorInterface.get_singleton() # Modify editor settings through the interface editor.get_editor_settings().set_setting("interface/editor/theme", "custom") # Access the base control to add UI elements var button = Button.new() button.text = "Custom Tool" button.pressed.connect(_on_button_pressed) editor.get_base_control().add_child(button) func _on_button_pressed(): var editor = EditorInterface.get_singleton() var selection = editor.get_selection() if selection.get_selected_node_count() > 0: var node = selection.get_selected_node(0) editor.edit_node(node) # Focus inspector on selected node ``` ### Creating a Custom Dock via C++ ```cpp // my_dock_plugin.cpp #include "editor/editor_interface.h" class MyDockPlugin : public EditorPlugin { GDCLASS(MyDockPlugin, EditorPlugin) Control *my_dock; public: void _enter_tree() override { my_dock = memnew(Control); my_dock->set_name("MyCustomDock"); // Add to EditorNode's base control hierarchy EditorInterface::get_singleton()->get_base_control()->add_child(my_dock); add_control_to_dock(DOCK_SLOT_RIGHT_UL, my_dock); } void _exit_tree() override { remove_control_from_docks(my_dock); memdelete(my_dock); } }; ``` ### Managing Editor Modes at Runtime ```gdscript # focus_mode.gd extends EditorPlugin func enable_distraction_free(): var editor = EditorInterface.get_singleton() # Toggle distraction-free mode to hide side panels editor.set_distraction_free_mode(true) # Access scene editing functionality var current_scene = editor.get_edited_scene_root() if current_scene: print("Currently editing: ", current_scene.name) ``` ## Summary - **EditorNode is a singleton Node** defined in [`editor/editor_node.h`](https://github.com/godotengine/godot/blob/main/editor/editor_node.h) and implemented in [`editor/editor_node.cpp`](https://github.com/godotengine/godot/blob/main/editor/editor_node.cpp) that instantiates the entire Godot editor as a scene-tree node within the engine process. - **Singleton access** is provided via `EditorNode::get_singleton()` (declared at line 44), with the static pointer initialized at line 205 and set during `NOTIFICATION_ENTER_TREE`. - **UI management** occurs through owned members like `main_menu_bar`, `center_split`, and `scene_tabs`, all rendered within the main viewport as standard Control nodes. - **Engine integration** happens through direct calls to `RenderingServer`, `DisplayServer`, and the resource system in methods like `_update_from_settings()`, enabling real-time synchronization of project settings. - **Plugin architecture** is managed through `Vector` and lookup maps, with public access abstracted through the `EditorInterface` class to maintain API stability. ## Frequently Asked Questions ### Is EditorNode available in exported games? No. EditorNode and the entire `editor/` directory are compiled only in editor builds using the `tools=yes` SCons flag. The singleton is not present in release exports, and any code referencing `EditorInterface` will fail to run in exported projects unless properly guarded with `Engine.is_editor_hint()` checks. ### How does EditorNode differ from regular game Nodes? While EditorNode inherits from `Node` and participates in the scene tree like any gameplay node, it sets `Engine::editor_hint` to true during `NOTIFICATION_ENTER_TREE` and owns the entire UI hierarchy including menus and docks. Unlike game nodes focused on gameplay logic, EditorNode manages the `EditorPlugin` system, file system scanning via `EditorFileSystem`, and resource import pipelines. ### Can multiple EditorNode instances exist simultaneously? No. The architecture strictly enforces a single instance through the static `EditorNode *singleton` pointer defined at line 205 of [`editor_node.cpp`](https://github.com/godotengine/godot/blob/main/editor_node.cpp). The constructor sets `singleton = this`, meaning any attempt to create a second instance would overwrite the global pointer and likely cause crashes during singleton access via `EditorNode::get_singleton()`. ### How does EditorNode handle scene saving and loading? EditorNode provides high-level methods `load_scene()`, `save_scene()`, and `close_scene()` that directly manipulate the engine's `SceneTree`. When loading, it creates the root node and adds it as a child of `scene_root` (a `SubViewport`), updates `editor_data` with scene metadata, and triggers `_update_title()` to reflect the current file in the window title. Saving uses `ResourceSaver` to serialize the scene and generates preview thumbnails through the editor's resource pipeline.