企业官网建设流程全解析

Amethyst 窗口数量上限（Window Limit）深度指南：配置、实现原理与 iPad 式多任务体验

【免费下载链接】AmethystAutomatic tiling window manager for macOS à la xmonad.项目地址: https://gitcode.com/gh_mirrors/am/Amethyst

Amethyst 是 macOS 上一款受 xmonad 启发的自动平铺窗口管理器，其「Window Limit（窗口数量上限）」功能允许你为每个屏幕设置同时保留的窗口数量上限，超出上限的窗口会被自动最小化，从而将混乱的多窗口工作区收敛为干净、可控的固定窗口集。本文基于 docs/window-limit.md 并结合仓库源码，完整讲解该功能的启用方式、底层执行机制、热键调节、推荐配置与已知限制，读完即可在真实环境中落地一套「窗口上限 + 布局切换」的高效工作流，甚至复刻出接近 iPad 的多任务体验。

一、功能概述：为什么需要窗口数量上限

在传统的平铺窗口管理器中，随着打开的窗口越来越多，每个窗口都会被压缩得越来越小，最终难以阅读。Amethyst 的 Window Limit 机制提供了另一种思路：不为所有窗口分配空间，而是限制可见窗口的数量——当某个屏幕上的窗口数量超过设定上限时，超出部分的窗口会被自动最小化，释放屏幕空间给真正活跃的窗口。

从默认配置看，该功能默认是关闭的。在 default.amethyst 中，对应键值默认为：

"window-max-count": 0

0即表示「不限制」。该配置键在 UserConfiguration.swift 中定义：

case windowMaxCount = "window-max-count"

其读取逻辑同样印证了「0 = 禁用」的约定（UserConfiguration.swift）：

func windowMaxCount() -> Int? { let int = Int(storage.float(forKey: .windowMaxCount)) return int == 0 ? nil : int }

当值为0时返回nil，即「无限制」；只有大于0时才返回具体上限。

二、如何启用：General 偏好设置中的 Maximum Window Count

启用方式非常直接：打开 Amethyst 的偏好设置（Preferences），进入General（通用）标签页，找到Maximum Window Count字段，填入一个大于0的数值即可启用该功能。

该字段在 GeneralPreferencesViewController.xib 中以Maximum Window Count:标签的形式存在于界面中，对应的配置键就是上文提到的window-max-count。

启用后，每个屏幕会遵循以下行为（详见下文第三、四节）：当窗口数超过上限时，超出的窗口被自动最小化；浮动窗口与主窗口（Main Pane）受到保护；限制按屏幕独立计算。

补充：通过热键实时调整上限

除了在偏好设置中手动填写数值，Amethyst 还提供了两套开箱即用的热键命令，用于在不打开设置面板的情况下动态调整窗口上限（HotKeyManager.swift）：

constructCommandWithCommandKey(CommandKey.increaseWindowMaxCount.rawValue) { self.userConfiguration.increaseWindowMaxCount() windowManager.markAllScreensForReflow() DispatchQueue.main.async { windowManager.displayWindowCountHUD() } } constructCommandWithCommandKey(CommandKey.decreaseWindowMaxCount.rawValue) { self.userConfiguration.decreaseWindowMaxCount() windowManager.markAllScreensForReflow() DispatchQueue.main.async { windowManager.displayWindowCountHUD() } }

对应的命令键定义在 UserConfiguration.swift：

case increaseWindowMaxCount = "increase-window-max-count" case decreaseWindowMaxCount = "decrease-window-max-count"

这两个命令会：

1. 修改配置值（increaseWindowMaxCount()/decreaseWindowMaxCount()，见 UserConfiguration.swift）；
2. 让所有屏幕重新执行布局（markAllScreensForReflow()）；
3. 通过 HUD 弹出当前窗口上限数值（displayWindowCountHUD()）。

其中递减逻辑使用max(0, currentCount - 1)保证下限不会低于0（即不会反向禁用下限保护），递增则从0起步加1，这为键盘驱动的工作流提供了便利。你可以在 Amethyst 的热键设置中为这两条命令绑定快捷键（HotKeyManager.swift 中的Increase window max count与Decrease window max count）。

三、行为机制详解：窗口是如何被挑选并最小化的

理解 Window Limit 的关键在于搞清楚「哪些窗口被保留、哪些被最小化」。下面结合源码拆解完整执行链路。

3.1 核心执行链路

整个机制由两条路径协作完成：

1. ScreenManager 计算最小化范围：ScreenManager.minimizeWindows()根据当前布局、主窗口数量与配置计算出「应该被最小化」的窗口索引区间（ScreenManager.swift）；
2. WindowManager 执行最小化：通过ScreenManagerDelegate.applyWindowLimit(forScreenManager:minimizingIn:)回调，对区间内的窗口逐个调用minimize()（WindowManager.swift）。

minimizeWindows()的入口守卫条件（ScreenManager.swift）：

guard UserConfiguration.shared.tilingEnabled, let windowLimit = UserConfiguration.shared.windowMaxCount() else { return }

这意味着只有当「Amethyst 平铺已启用」且「窗口上限大于 0」时，最小化逻辑才会执行。这两条守卫条件正是文档中两条行为规则的代码级体现（见 3.4 与 3.5 节）。

实际的最小化动作由Window.minimize()完成，它调用系统级最小化并返回窗口是否已处于最小化状态（Window.swift）：

@discardableResult func minimize() -> Bool { super.minimize() return isWindowMinimized() }

3.2 浮动窗口不会被最小化

文档明确约定：使用键盘快捷键设置为浮动（Float）的窗口不会被最小化。这一点在WindowManager.applyWindowLimit中体现得尤为直接——当当前布局是 Floating Layout 时，参与「被最小化候选」的窗口会先经过shouldBeManaged()过滤（WindowManager.swift）：

let windows = screenManager.currentLayout is FloatingLayout ? self.windows(onScreen: screen).filter { $0.shouldBeManaged() } : activeWindows(on: screen) windows[range(windows.count)].forEach { $0.minimize() }

也就是说，浮动窗口被视为「应被管理的窗口」之外的存在，天然豁免于窗口上限的清理逻辑，适合作为常驻的参考信息、即时通讯等窗口。

3.3 主窗口（Main Pane）的豁免与两种模式

文档第二条行为规则：主窗口不会被最小化，且其具体行为取决于「Send new windows to main pane」（对应配置键new-windows-to-main，默认false，见 default.amethyst）这一开关：

• 开启「Send new windows to main pane」：新窗口优先进入主窗口区，当窗口数超限时，最旧的窗口被轮换（cycle out）并最小化，保证主窗口始终保留；
• 关闭该开关：主窗口区被排除在最小化范围之外，主窗口成为一个持续存在的固定工作区（persistent workspace），与其他窗口并存。

底层实现在minimizeWindows()中按分支处理（ScreenManager.swift），核心思路是：

• 先取当前布局的主窗口数量：let mainPaneCount = (currentLayout as? PanedLayout)?.mainPaneCount ?? 0（非 Paned 布局视为 0）；
• 若windowLimit <= mainPaneCount，说明上限小于等于主窗口数量，此时绝不触碰主窗口，只最小化主窗口之后的非主窗口（return mainPaneCount ..< windowCount）；
• 若windowLimit > mainPaneCount，则依据sendNewWindowsToMainPane()的取值决定从窗口序列的头部还是尾部开始最小化，实现「最旧窗口轮换」的效果。

源码注释也明确说明了这一设计意图：「Don't minimize main panes. This allowing varying main pane count to pin windows.」（不最小化主窗口，从而允许通过调整主窗口数量来"钉住"某些窗口）。

3.4 限制按屏幕独立计算

Window Limit按屏幕（per-screen）独立生效。从架构上看，每个屏幕由独立的ScreenManager实例管理（ScreenManager.swift），窗口的最小化范围计算发生在每个ScreenManager自己的minimizeWindows()内，互不共享状态。因此，如果你在副屏上设置了与主屏不同的窗口上限，两个屏幕会各自独立收敛窗口数量，互不干扰。

3.5 与全局启停、布局类型的联动

文档还包含两条容易被忽略但很重要的行为约定：

1. 禁用 Amethyst 会同时禁用窗口上限：这正对应 3.1 节中的守卫条件UserConfiguration.shared.tilingEnabled。当你在菜单栏关闭 Amethyst（即关闭平铺功能）时，minimizeWindows()会直接return，不再执行任何最小化，窗口上限随之失效。
2. 使用 Floating 布局可以在不平铺窗口的情况下应用窗口上限：Floating Layout 不参与窗口平铺，但setNeedsReflow()依然会触发minimizeWindows()（ScreenManager.swift），且applyWindowLimit对 FloatingLayout 做了专门处理（见 3.2 节），因此你可以在完全不使用平铺布局的前提下，仅靠窗口上限来约束可见窗口数量——这为「只想要自动收拢、不想要平铺」的用户提供了折中方案。

四、推荐配置：打造干净的 Dock 与 iPad 式体验

4.1 配合 macOS Dock 设置，避免 Dock 堆积

由于超限窗口会被持续最小化，Dock 中会积累越来越多的最小化窗口图标。文档建议：在System Preferences（系统偏好设置）→ Dock 面板中启用「将窗口最小化为应用程序图标」（Minimize windows into application icon），这样窗口最小化后只会缩进对应 App 的 Dock 图标，而不会在 Dock 中生成独立的最小化窗口缩略图，从而避免长时间使用该功能时 Dock 变得杂乱。

4.2 复刻 iPad 式多任务体验的完整配方

文档给出了一套非常具体的「iPad 化」配置组合，适合希望获得类似 iPad 全屏/分屏切换体验的用户：

1. 窗口上限设为 2：在任何时刻，屏幕上最多保留 2 个窗口；
2. 只启用 Fullscreen 布局与一个「分栏类」布局（paned layout，如 Tall、Column 等）：仅保留这两种布局用于切换；
3. 在两个布局之间循环切换：Fullscreen 布局即 iPad 的「全屏」模式，分栏布局即 iPad 的「分屏视图（Split View）」，通过 Amethyst 的布局循环热键即可来回切换（底层对应ScreenManager.cycleLayoutForward()/cycleLayoutBackward()，见 ScreenManager.swift）；
4. 启用「Swap windows using mouse」与「Resize windows using mouse」：分别对应配置键mouse-swaps-windows与mouse-resizes-windows（见 UserConfiguration.swift），使鼠标能够像 iPad 分屏那样拖动交换窗口位置、拖拽调整分栏比例；
5. 将需要「悬浮」的窗口通过快捷键设为浮动：浮动窗口不被最小化（见 3.2 节），且悬浮在其他窗口之上，正好模拟 iPad 的Slide Over（侧滑浮窗）模式。

这套组合的核心思想是：用「窗口上限 = 2 + 布局循环」替代 iPad 的 Scene 管理，用「浮动窗口」替代 Slide Over，用「鼠标交换/缩放」替代触控手势，在 macOS 上获得近似 iPad 的多任务节奏。

五、已知限制与注意事项

文档明确列出该功能当前存在的限制：

• 窗口在屏幕间移动时，窗口上限可能不会被强制执行：当用户把窗口从一个屏幕拖到另一个屏幕时，由于窗口集合的更新时机问题，目标屏幕的窗口数可能暂时超出上限。文档给出的解决办法是——新建一个窗口即可纠正该问题（创建新窗口会触发一次完整的 reflow 与最小化流程，从而重新收敛窗口数量）。

此外，结合源码还可补充两点注意事项：

• 数值 0 的特殊语义：window-max-count为0表示禁用（返回nil），任何大于 0 的值才会触发限制逻辑。如果你通过热键「Decrease window max count」递减，数值最低只能到0，不会出现负数；
• 与平铺开关的耦合：只要关闭 Amethyst 的平铺（tilingEnabled），窗口上限便一并失效；若希望「只限数量、不平铺」，请选择 Floating 布局而不是直接关闭 Amethyst。

六、关键实现与配置路径速查

以下是本文涉及的核心源码与配置文件，便于进一步深入阅读：

• 功能文档：docs/window-limit.md
• 配置键与读写逻辑：UserConfiguration.swift、UserConfiguration.swift、UserConfiguration.swift
• 默认配置值：default.amethyst、default.amethyst
• 最小化范围计算：ScreenManager.swift
• 最小化执行与浮动过滤：WindowManager.swift
• 窗口最小化动作：Window.swift
• 热键命令注册：HotKeyManager.swift
• 偏好设置界面字段：GeneralPreferencesViewController.xib

把握住「上限数值 + 主窗口保护 + 浮动豁免 + 按屏独立」这四条核心规则，再配合热键动态调节与 Floating 布局的灵活组合，Window Limit 完全可以成为 Amethyst 工作流中一个高价值的生产力组件。

【免费下载链接】AmethystAutomatic tiling window manager for macOS à la xmonad.项目地址: https://gitcode.com/gh_mirrors/am/Amethyst