XCEngine/docs/api/XCEngine/Editor/Actions/ActionRouting/ActionRouting.md

ActionRouting

命名空间: XCEngine::Editor::Actions

类型: header-helper

源文件: editor/src/Actions/ActionRouting.h

描述: 根据当前 ImGui 窗口焦点更新 EditorActionRoute，让 Edit 菜单和快捷键知道“当前应该作用于哪个面板”。

概述

ActionRouting.h 提供的是一组很小但很关键的粘合函数：

• ObserveFocusedActionRoute 在当前窗口获得根窗口焦点时，把上下文的活动路由设置为指定值
• ObserveInactiveActionRoute 把活动路由显式重置为 EditorActionRoute::None
• IsActionRouteActive 用于查询当前路由

这层设计的意义，不是再造一套复杂命令系统，而是把“UI 焦点”翻译成“编辑目标”。这样 ProjectPanel 获得焦点时，Delete 可以删除资源；HierarchyPanel 获得焦点时，同样的按键变成删除实体。

当前实现

• 路由判断直接依赖 ImGui::IsWindowFocused(ImGuiFocusedFlags_RootAndChildWindows)
• 没有独立的焦点管理器，也没有优先级仲裁器
• 当前只有 Hierarchy、Project 和 None 三种路由状态
• HierarchyPanel 与 ProjectPanel 会设置显式路由；InspectorPanel 与 ConsolePanel 当前会调用 ObserveInactiveActionRoute

设计说明

这是一种很典型的商业编辑器做法：把“全局 Edit 菜单”做成上下文敏感，而不是把复制、粘贴、删除分别硬编码进每个面板。
相对 Unity、Unreal 这类编辑器，这里的实现还很轻量，但方向是一致的：

• 面板负责声明自己何时成为当前编辑目标
• EditActionRouter 负责根据当前目标解析动作
• Commands 层负责真正落地状态变更

这样拆开以后，快捷键、菜单栏和右键菜单可以共享同一套行为，不容易出现同一操作在不同入口行为不一致的问题。

当前限制

• 焦点路由完全依赖 ImGui 窗口焦点，尚未覆盖更细粒度的控件级编辑上下文
• Inspector 尚未注册独立路由，因此它不会接管全局 Edit 行为
• 没有多窗口、多文档或浮动工具窗之间的冲突处理策略

相关文档

• Actions
• EditorActions
• EditActionRouter
• EditorActionRoute