Komorebi窗口管理器中的堆栈窗口循环Bug分析与解决方案

在Komorebi窗口管理器0.1.29+版本中发现了一个关于堆栈窗口循环的重要Bug。当用户将堆栈容器设置为单窗口模式(monocled)时，cycle-stack和focus-stack-window命令将无法正常工作。这个问题源于窗口管理器在单窗口模式下对焦点容器处理的逻辑缺陷。

问题本质

Komorebi的窗口管理架构中，当容器进入单窗口模式时，系统会将焦点容器从工作区容器环(containers ring)中移除，并将其移动到单窗口容器。然而，cycle-stack和focus-stack-window命令仍然尝试从工作区容器环中获取self.focused_container，导致无法正确识别当前处于单窗口模式下的焦点窗口。

技术背景

窗口管理器的容器管理通常采用以下几种数据结构：

1. 工作区容器环(containers ring)：管理常规布局下的窗口容器
2. 单窗口容器(monocle container)：存储单窗口模式下的焦点窗口
3. 浮动窗口列表(floating_windows)：管理浮动窗口

当前实现的问题在于容器在不同状态间的转移破坏了数据结构的一致性。当容器进入单窗口模式时，它被从工作区容器环中移除，导致后续操作无法通过常规路径访问该容器。

解决方案思路

短期解决方案可以通过在命令执行时添加对单窗口容器的检查逻辑来解决。具体实现是在执行堆栈循环命令前，先检查当前是否处于单窗口模式，如果是则从单窗口容器获取焦点窗口。

更理想的架构改进方案是保持容器始终存在于工作区容器环中，仅通过状态标志来区分容器当前模式。这种设计有以下优势：

1. 保持数据结构一致性
2. 简化焦点管理逻辑
3. 支持更灵活的状态转换
4. 便于实现浮动窗口的焦点记忆功能

实现建议

对于当前问题的修复，建议采用以下伪代码逻辑：

fn get_focused_container() -> Option<Container> {
    if is_monocled() {
        return monocle_container.get_focused()
    } else {
        return workspace_ring.get_focused()
    }
}

长期来看，重构容器管理系统可以考虑：

1. 使用状态模式设计容器
2. 统一容器标识管理
3. 实现更健壮的焦点跟踪机制

影响评估

该Bug主要影响使用单窗口模式的用户，特别是在需要快速切换堆栈中窗口的工作流中。修复后将提升以下场景的体验：

1. 编程时在单窗口和常规布局间切换
2. 文档编辑时的多窗口管理
3. 需要频繁聚焦不同窗口的工作流程

这个问题也提示我们在设计窗口管理器时需要考虑不同显示模式间的状态一致性，确保核心功能在所有模式下都能正常工作。