Editor

命名空间: XCEngine::Editor

类型: app-module

描述: XCEngine 独立编辑器应用层 API 文档入口，对应 editor/src/** 的模块结构，覆盖应用启动、上下文、面板、布局、命令、动作路由与 UI 基础设施。

概述

这一组文档对应的不是 engine/include/XCEngine/** 那类“引擎公共运行时头文件”，而是编辑器应用本身的源码模块。换句话说，这里的 API 更接近“工具层架构说明”和“编辑器内部可复用接口”，而不是给游戏运行时代码直接依赖的稳定 SDK。

当前 Editor 的主链路可以概括为：

从架构视角看，Editor 模块解决的是“如何把引擎运行时能力组织成一个可编辑、可观察、可操作的工具应用”。

这和商业游戏引擎的常见分层非常一致：

因此阅读这套文档时，最重要的前置认知是：Editor 层的很多接口是为工具体验服务的，它们允许比运行时 API 更强的耦合、更明确的 UI 约束和更直接的产品导向。

结合当前 editor/src 的实现，Editor 文档当前有几个结构上非常重要的重构点：

UI.h 现在明确作为 umbrella header 处理，其职责是聚合常用 UI helper，而不是声明新的运行时类型。
TreeView、PropertyLayout、BuiltInIcons、DockTabBarChrome 等新基础设施已经成为多个面板共享的 UI 基建。
HierarchyPanel 和 ProjectPanel 的实现已经明显转向“面板只负责呈现与路由，动作层 / 命令层负责执行业务”的分层。

这意味着 Editor 文档不能只做目录映射，还必须解释这些共享基础设施为什么存在、它们如何把编辑器代码从面板私有技巧提升为稳定的产品层模式。

并不是 editor/src/** 下每个文件都值得成为单独 API 页。当前有几类文件更适合在模块页说明：

editor/src/UI/UI.h 这是 UI 子模块的 umbrella header，文档并入 UI。
editor/src/EditorResources.h 当前只定义了 IDI_APP_ICON 101，用于 EditorApp.rc 的资源 id 绑定，更适合作为 Editor 应用资源入口说明，而不是独立类型页。
editor/src/EditorApp.rc、editor/src/main.cpp 属于应用启动与资源清单支撑文件，不是面向上层复用的编辑器 API。

这种处理方式符合当前文档规范：只有真正承担模块职责或可复用契约的文件才进入 canonical API 树；纯资源声明和应用入口支撑文件优先并入模块说明。

当前编辑器主路径仍然以 Windows + D3D12 + Dear ImGui 为核心。
这套代码整体属于应用层源码，不应误解为已经整理成稳定插件 SDK。
自动审计脚本目前主要覆盖 engine/include/XCEngine/** 的 public headers；Editor 这组文档更依赖目录并行约束、链接校验和人工核对源码行为。