Hammerspoon中解决AppleScript访问自身菜单栏的疑难问题

问题背景

在使用Hammerspoon开发自动化工具时，开发者经常需要通过AppleScript与系统交互。一个典型场景是控制Bartender这类菜单栏管理工具显示/隐藏特定菜单项。然而当AppleScript尝试通过"System Events"访问Hammerspoon自身的菜单栏时，会遇到"Can't get last menu bar"的错误，这个问题仅在目标应用是Hammerspoon自身时出现。

问题本质

经过深入分析，这个问题源于Hammerspoon的执行机制特性：

1. 主线程阻塞：Hammerspoon的模块（包括hs.osascript）默认在主线程运行
2. 死锁风险：当AppleScript通过System Events请求访问Hammerspoon的菜单栏时，Hammerspoon正忙于执行脚本而无法响应
3. 超时机制：最终System Events因得不到响应而报错

解决方案

方案一：直接调用菜单弹出功能

Hammerspoon的hs.menubar模块本身就提供了直接弹出菜单的方法，无需通过Bartender：

hs.hotkey.bind({'cmd', 'ctrl'}, 'p', function()
    proxyMenu:popupMenu(hs.mouse.absolutePosition())
end)

优势：

• 完全绕过Bartender的限制
• 响应迅速无延迟
• 可精确定位弹出位置

方案二：利用Bartender内置热键

Bartender自身提供了配置热键显示隐藏菜单项的功能，这种方法：

• 配置简单直观
• 系统资源占用低
• 无需额外代码维护

方案三：设置菜单项autosaveName

通过设置菜单项的autosaveName属性，可以稳定标识菜单项：

proxyMenu:autosaveName("Proxy Menu")

hs.hotkey.bind({'cmd', 'ctrl'}, 'p', function()
    hs.osascript.applescript([[
        tell application id "com.surteesstudios.Bartender"
            activate "org.hammerspoon.Hammerspoon-Proxy Menu"
        end
    ]])
end)

技术原理：

• 每个菜单项都有autosaveName属性
• 默认使用Item-0/1/2等自动命名
• 自定义名称可确保稳定引用

方案四：使用hs.axuielement模块

Hammerspoon的辅助功能API可以避免死锁问题：

local axHammerspoon = hs.axuielement.applicationElement(hs.processInfo.processID)
local proxyMenuFrame = proxyMenu:frame()
local proxyMenuID

for i, axMenuBarItem in ipairs(axHammerspoon.AXExtrasMenuBar.AXChildren) do
    if hs.geometry(axMenuBarItem.AXFrame).center:inside(proxyMenuFrame) then
        proxyMenuID = ("%s-Item-%d"):format(hs.processInfo.bundleID, i-1)
        break
    end
end

注意事项：

• 需要处理多显示器情况
• 索引从0开始计算
• 需确保菜单项已加载

最佳实践建议

1. 简单场景优先：若无特殊需求，直接使用方案一最为可靠
2. 长期稳定性：需要与Bartender深度集成时，方案三最为健壮
3. 性能考量：方案四虽然灵活但实现较为复杂
4. 错误处理：所有方案都应添加适当的错误检查和回退机制

总结

Hammerspoon作为强大的macOS自动化工具，在访问自身UI元素时需要特别注意执行上下文和线程问题。通过理解底层机制并合理选择解决方案，开发者可以构建出既稳定又高效的自动化工作流。本文提供的四种方案各有适用场景，开发者应根据具体需求选择最合适的实现方式。