RFC: 探索 MooTool 的 macOS 原生 SwiftUI 版本

[CassianFlorin]

RFC: 探索 MooTool 的 macOS 原生 SwiftUI 版本

背景

MooTool 目前是一个 Java/Swing/FlatLaf 的跨平台开发者工具，已经支持 Windows、Linux 和 macOS。macOS 侧也已经有单独的 DMG 构建产物，例如 GitHub Actions 中已有 mac-apple-silicon、mac-intel、windows-x64、linux-x64 等目标分流。

我想先征求维护者和社区意见：是否可以探索一套 macOS 原生 SwiftUI/AppKit 版本，让 macOS 用户获得更贴近系统的窗口、菜单、快捷键、主题、权限和安装体验。

这个提议不是要求立刻废弃现有 Java 版本，也不是要一次性把整个项目改成 macOS-only。

提议目标

• 保留现有 Java 版作为 Windows/Linux 的主线实现，macOS 也可以继续保留 Java 包作为稳定版本。
• 新增一个 macOS-only 的 SwiftUI 原生版本，前期作为 preview/beta 方向探索。
• 优先改善 macOS 体验相关能力：原生菜单栏、窗口行为、快捷键、深浅色主题、权限提示、签名/公证、DMG 安装体验。
• 后续按功能分批迁移，而不是一次性提交一个完整重写的大 PR。

非目标

• 不在第一个 PR 中替换正式 macOS DMG。
• 不影响 Windows/Linux 的 Java 打包和发布流程。
• 不要求维护者立即承担完整 SwiftUI 版本的长期维护成本。
• 不把现有 Java/Swing 代码直接逐文件翻译成 SwiftUI。

建议路线

阶段 0：先讨论方向

先通过这个 Discussion/RFC 确认维护者是否接受 macOS 原生版方向，以及希望它以什么形式存在：

• 仓库内新增 macos/ 子工程；
• 或者独立仓库维护；
• 或者先只接受设计文档，暂不接收代码。

阶段 1：最小骨架 PR

如果方向可接受，第一批 PR 只做低风险基础设施：

• 新增 macos/ SwiftUI 工程骨架；
• 增加基础 README，说明本地构建方式；
• 在现有 GitHub Actions 中增加手动触发的 SwiftUI macOS 构建目标；
• 不进入 tag release，不替换现有 Java macOS 包。

阶段 2：基础能力 PR

再逐步加入：

• 应用导航框架；
• 设置页；
• SQLite 数据导入；
• 通用编辑器、结果面板、历史记录等基础组件；
• 与现有 ~/.MooTool/MooTool.db 的导入兼容能力。

阶段 3：功能分批迁移

按模块分批迁移，例如：

• 文本/JSON/编码/时间转换等低权限工具；
• 二维码、图片、颜色、正则、Cron 等中等复杂度工具；
• HTTP、Host、网络诊断、PDF、Java/Groovy 相关能力等高权限或高依赖工具。

阶段 4：是否替换正式 macOS 包

等 SwiftUI 版本功能覆盖、稳定性和安装体验达到要求后，再讨论是否：

• 继续并列发布 Java macOS 包和 SwiftUI macOS 包；
• 或将正式 macOS DMG 替换为 SwiftUI 版本；
• 或只把 SwiftUI 版作为实验版本长期保留。

数据兼容建议

SwiftUI 版建议采用“导入兼容”，而不是直接共用旧库长期读写：

• 首次启动时检测旧数据目录 ~/.MooTool/；
• 从 MooTool.db 导入随手记、JSON、HTTP 请求、Host、二维码、收藏颜色、正则、Cron、文本对比等核心数据；
• 导入后 SwiftUI 版使用自己的数据目录，降低新旧版本互相影响和回滚风险；
• 如维护者希望完全共用旧库，也可以在后续阶段单独讨论。

CI/发布建议

上游目前已经有按平台区分的构建 workflow，因此 SwiftUI 版可以只影响 macOS 分支：

• 初期只增加 workflow_dispatch 手动目标，例如 mac-swiftui-preview；
• 不改变 mac-apple-silicon、mac-intel、windows-x64、linux-x64 现有构建；
• 不在 tag release 中默认上传 SwiftUI 产物；
• 等维护者确认后，再决定是否加入正式 release assets。

希望确认的问题

1. 维护者是否接受在 MooTool 中探索 macOS 原生 SwiftUI 版本？
2. 如果接受，更希望放在当前仓库的 macos/ 子工程，还是独立仓库？
3. 第一阶段是否可以只提交“工程骨架 + 手动构建 + README”，不迁移具体功能？
4. macOS 原生版最终更适合并列发布，还是在稳定后替换现有 macOS Java DMG？
5. 对旧数据兼容策略，维护者更倾向“导入兼容”还是“长期共用旧 SQLite 库”？

如果方向可行，我可以先准备一个很小的骨架 PR，确保不影响现有 Java 主线和 Windows/Linux 发布流程。

[rememberber]

谢谢你，亲爱的朋友❤️

维护者是否接受在 MooTool 中探索 macOS 原生 SwiftUI 版本？

接受并且欣赏该做法。

如果接受，更希望放在当前仓库的 macos/ 子工程，还是独立仓库？

子工程，谢谢。

第一阶段是否可以只提交“工程骨架 + 手动构建 + README”，不迁移具体功能？

完全可以，👍

macOS 原生版最终更适合并列发布，还是在稳定后替换现有 macOS Java DMG？

先并列，发展完整后可替换。

对旧数据兼容策略，维护者更倾向“导入兼容”还是“长期共用旧 SQLite 库”？

导入兼容或者不兼容都可以，因为旧结构并不完美。

[CassianFlorin]

谢谢你的支持🫰
目前已经完成了第一阶段的提交✅

[CassianFlorin]

最近有点忙，更新进行要放缓了