bismuth

项目背景与痛点

KDE Plasma 的窗口管理能力并不弱。KWin 自带 Quick Tile，窗口拖到屏幕边缘就能半屏吸附。但 Quick Tile 和 i3wm、Sway、dwm 那套「窗口自动铺满、永不重叠、焦点即主窗」的模型有本质区别：KWin 的拼贴是一次性动作，窗口贴完之后就脱离布局关系，新开的窗口不会自动让位，关掉的窗口留下的空洞也不会被填补。你要的是工作流，它给的是一次操作。

Bismuth 的存在理由就在这儿：在不改动一行 KWin 源码的前提下，把 i3 式的平铺语义搬到 Plasma 上。它的前身是 Krohnkite，Bismuth 作为继任分支保留了核心抽象，同时用 TypeScript 重写、补齐配置体系与长期维护能力。这件事的分量在于，桌面级 tiling 过去只有两条路——换掉整个 compositor（i3/Sway），或者给 KWin 打补丁维护一个魔改分支。Bismuth 选择了第三条：寄生在 KWin 的脚本层之上，用事件订阅和几何写回，硬生生造出 tiling 语义。

核心技术揭秘

技术栈是 TypeScript + KWin Scripting API + KConfigXT。TypeScript 这个选择很关键：KWin 只接受一个能被 QJSEngine 加载的 JS 文件，运行时没有模块系统，因此 Bismuth 必须靠打包器把所有源码压成单文件产物；而 Tile 树这种多层嵌套的状态机，如果没有类型系统兜底，几乎必然会写崩。这在 KWin 脚本生态里属于相当罕见的工程化水平。

架构上是清晰的 MVC 变体，计算与副作用严格分离：

核心数据模型是一棵树：每个虚拟桌面一棵 Tile 树，节点是 Tile 或容器节点，父子关系表达行列嵌套。每个 Tile 带状态（Tile / Float / Monocle / Half / Quarter / Unmanaged），状态决定它在树里是否参与布局。

布局引擎是策略模式的教科书用法：Layout 暴露统一的 layout(ctx, tile) 接口，Half 平分、Quarter 四格、ThreeColumn 三栏、Spiral 螺旋递归，各自只负责产出矩形，完全不碰 KWin 对象。正因如此，布局才能被单测覆盖，也才能随时新增。

真正的脏活全在几何：workspace.clientArea 要给 Plasma 面板让位，窗口装饰尺寸、最小尺寸约束、gap 配置都得在应用前修正，少算一个 decoration 就能看到 1px 的缝。数据流是事件驱动 + 幂等重排——KWin 抛出窗口增删、激活、移动、最大化一长串信号，Engine 更新树后触发一次全量 relayout；为避免事件风暴，必须有防抖和「几何无变化就不写回」的短路判断，否则窗口会肉眼可见地抖。状态持久化同样棘手：Tile 树序列化进 KConfig，Plasma 重启后窗口 ID 全变，恢复逻辑一不小心就把整棵树搞乱。

功能亮点与差异

杀手锏是键盘模型的完整度。方向键 focus/move/push、i3 同款的 Resize mode、布局切换、monocle 模式，快捷键覆盖面在 KWin 插件里数一数二。布局种类（Half / Quarter / ThreeColumn / Spiral / Spread / Stacked / Cascade）也超出同类脚本，且支持每桌面独立树、每窗口独立状态，粒度比 i3 的 workspace 更细。

其次是零侵入。不 patch KWin、不改 Plasma，装一个 KWin Script 就能跑，卸载即恢复原状。这是相对魔改分支的决定性优势。配置走 Plasma 系统设置的图形界面，KConfigXT 自动生成，不需要手改 JSON。

横向对比：跟 i3/Sway 比，它不是 compositor，没有原生拖拽插入指示器、没有 scratchpad；跟 Krohnkite/Karousel 比，它的维护活跃度、TypeScript 工程化和新版 Plasma 适配是主要差距；跟 KWin 自带 Quick Tile 比，它是持续状态而非一次性动作——这一条就是全部差别。

应用场景与落地建议

最适合键盘重度依赖的开发者、需要多窗口等分对照的运维与数据分析岗，以及习惯 i3 但被 Plasma 生态锁死的用户。落地前有几件事必须想清楚：

Bismuth 与 KWin API 强耦合，升级 Plasma 大版本前先看 release note，脚本层的私有 API 变动是常态。其次要明确定义与 KWin 自带 Quick Tile、窗口规则、最大化行为的优先级关系，否则会出现「贴完又弹回去」的诡异现象。多显示器场景下 Tile 树按虚拟桌面而非按屏幕组织，跨屏布局会有反直觉表现。Wayland 下脚本权限仍有边界，别指望它能做到 X11 时代的一切。最后，Spiral 递归加几十个窗口的同步 relayout 会掉帧，低配机器上谨慎堆窗口。

综合评价

优点：方向正确，工程化扎实，配置完整，零侵入，社区仍在维护。它把「KWin 脚本到底能做到什么程度」这个问题的答案往前推了一大截。

缺点：寄生架构决定了天花板。没有 compositor 层控制权，拖拽交互、窗口组、scratchpad、真正的 per-output 布局，都很难做到 i3 的纯度；Plasma 版本适配是长期负担；布局切换缺乏视觉过渡，观感粗糙。

一句话：它不负责替代 i3，它是 Plasma 上最接近 i3 语义的可行解。愿意接受 KWin 的模型边界，这就是目前最省事的平铺方案。