桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载导读本篇以仓库中的增量开发记录 next-compose/docs/diff/561-mcp-reformat-update-env-net-vault-css-slice.mdDIFF-561为线索还原 MooTool Next-Compose 桌面版在一次功能切片中如何把 MCP stdio 工具、格式化引擎、更新下载流、Vault 底栏与 F08/F11/F25 工具 UI 逐个“可测化、可验证化”落地。文章会逐条对照行为清单深入对应 Kotlin 源码与桌面测试解释每个守卫条件、配置参数与验证脚本的实际含义。读完你可以直接读懂这套增量开发的工作方式并能在本地复现其验证流程。背景一次以“可测化”为验收标准的增量切片DIFF-561 承接 DIFF-560 已有的工作F17/F03enabled守卫、Vault GitsaveRemoteEnabled、MCP stdiomootool_encode、设置分类导航mooSettingsNavItem与 Compose 帧154明确“不重复”上一轮的守卫、Git 远程保存、设置导航与 MCP 编码链只专注于本条新增范围。同时文档记录了尚未达成的 parity-gap六套 CSS 逐选择器皮肤、产品主窗 Tab/IME/TCC PNG、P7 三平台安装等 substantial 缺口仍未关闭。从开发方法看这条文档的核心不是“堆功能”而是把六个横切面MCP 子进程、格式化引擎、更新流、Vault 底栏、工具 UI、CSS 组件全部收敛到可运行的测试与可复现的证据帧上这正是本仓库 next-compose/docs/acceptance.md 与 next-compose/docs/baseline.md 所强调的工程惯例。一、MCP stdio让mootool_hash/diff/json_query以子进程方式往返1.1 为什么用子进程 stdio 测试MooTool Next-Compose 通过 MCPModel Context Protocol把本机工具暴露给 AI 客户端。为了在 JVM 桌面工程里验证完整链路服务端启动 → 握手 → 工具调用 → 结果回传测试使用真正的StdioClientTransport拉起一个独立子进程而不是 mock 内部函数。这能同时验证命令参数解析、--access-file授权文件、MCP 协议初始化与 JSON 序列化。启动解析器见 McpLaunchResolver.ktfun clientLaunch(accessFile: Path): McpLaunch { val command ProcessHandle.current().info().command().orElse(javaBinary()) val args listOf(--mcp, --access-file, accessFile.absolutePathString()) return McpLaunch(command command, args args) }访问授权文件固定生成在configRoot/ai-integration/access.json测试中写入{version:1}作为最小授权面。1.2 三个子进程往返用例AiIntegrationMcpHashDiffJsonQueryTest.kt 一次测试覆盖三个工具工具调用参数示例断言要点mootool_hash{text:abc}返回 SHA-256 十六进制ba7816bf...15admootool_diff{left:one\n,right:two\n}返回非空且包含-或原文mootool_json_query{text:{\values\:[1,2]},path:$.values[*]}结果同时含1和2同步客户端统一requestTimeout(Duration.ofSeconds(15))通过McpClient.sync(transport)建立会话后依次callTool。1.3 时间戳与 UUID 往返AiIntegrationMcpTimestampUuidTest.kt 覆盖剩余两个工具其中mootool_timestamp的断言非常精确mapOf( text to 1970-01-01 08:00:00, direction to to-timestamp, zone to Asia/Shanghai, ) // 断言返回 0即“东八区 1970-01-01 08:00:00”恰好对应 Unix 纪元 0验证了时区归一化逻辑mootool_uuid则请求{count:2}并断言返回 JSON 数组长度为 2、且两个 UUID 互不相同。二、F03 格式化从“只守卫”到“引擎可测”2.1 Presentation 层的守卫与引擎调用DIFF-561 的关键是把 F03 格式化从“仅有 enabled 守卫”推进到真实调用引擎。层与层职责在 ReformatWiringPresentation.kt 中划分清晰fun runFormat(input: String, type: ReformatType, indent: Int): FormatRunOutcome runCatching { ReformatEngine.format(input, type, indent) }.fold( onSuccess { FormatRunOutcome.Success(it) }, onFailure { FormatRunOutcome.Failure(it) }, )同时提供一组守卫函数canRunFormat / formatActionEnabled!busy inputNotBlank即“忙时或输入为空时禁用格式化钮”copyResultActionEnabled / saveResultActionEnabled输出isNotBlank()才可复制/另存defaultSaveFileName按类型生成扩展名源码为空则回退为formatted.conf等默认名inferTypeFromFileNameconf/nginx → Nginx、java → Java、xml/xsd/svg → Xml、html/htm → Html其余返回null。错误消息也做了定位化当ReformatException携带line 1时返回reformat.error.located带行/列/原始消息参数否则返回通用键reformat.error.generic。2.2 引擎层四种格式的真实实现ReformatEngine.kt 覆盖 Nginx / Java / XML / HTML 四种类型Nginx自写 tokenizer处理引号、转义、#注释、{}、;与换行按{层级缩进缩进宽度coerceIn(1, 8)Java基于 JavaParser 的StaticJavaParser.parseDefaultPrettyPrinter语法错误抛出携带行列的ReformatExceptionXML安全化的DocumentBuilderFactory关闭 DOCTYPE 与外部实体、启用FEATURE_SECURE_PROCESSING、禁用 XInclude解析失败同样抛出带行列号的异常HTML基于 jsoup 的Parser.htmlParser()对文本/元素/注释/数据节点分块输出。每种类型都内置了samples示例文本方便直接试跑。演示把server { listen 80; location / { proxy_pass http://127.0.0.1:3000; } }交给ReformatEngine.format(input, ReformatType.Nginx, 2)即可得到缩进后的多行配置。2.3 对应测试覆盖ReformatWiringPresentationTest.kt 共 8 个用例覆盖失败 toast 判定、忙碌/空输入守卫矩阵、工具栏按钮 enabled 映射、默认另存文件名、Nginx 真实格式化输出、带行号的错误消息、扩展名推断、文件读取含类型推断。运行ReformatEngineTest.kt则可直接验证引擎各类型输出。三、更新下载流check(autoDownload)与applyAutoDownloadSetting的完整闭环3.1 协调器职责UpdateCoordinator.kt 用StateFlowUpdateUiState驱动 UI状态机包含idle → checking → available/downloading → ready → error/cancelled并对外暴露五个动作check(currentVersion, autoDownload, automatic) download() applyAutoDownloadSetting(enabled) cancel() openInstaller()关键点在于两处分支check(autoDownload true)且结果为Available且尚未下载就绪时自动触发performDownload()applyAutoDownloadSetting(true)时若上次检查已Available且满足UpdateAutoDownloadTrigger.shouldStartDownload(...)的条件未忙、有下载包、未就绪则立即开始下载。下载过程通过UpdateProgress(transferred, total)回报进度完成后status ready并写入安装包Path。3.2 引擎层清单解析与资产选择UpdateEngine.kt 负责可独立测试的纯逻辑平台/架构归一化darwin/win32/linux×arm64/x64版本比较compareVersions含 prerelease 分段、数字段零填充校验清单校验schemaVersion 1、status active、版本不重复、asset 的sha512必须匹配^[A-Za-z0-9/]{86}$、文件名不含路径分隔符且长度 ≤ 240、size 0、所有 URL 强制 HTTPS资产选择selectAsset按平台/架构匹配universal可兜底darwin仅接受dmg再按「架构精确优先 → priority → 包类型偏好」排序各平台包类型偏好顺序见packagePreference如darwin: dmg pkg。默认 feed 常量DEFAULT_FEED指向仓库的update-manifest.jsonMAX_MANIFEST_BYTES 2 * 1024 * 1024限制响应体上限协调器还允许通过环境变量MOOTOOL_COMPOSE_UPDATE_FEED_URL覆盖 feed 地址。3.3 两条下载流测试UpdateCoordinatorDownloadFlowTest.kt 使用 mock 的textFetcher返回 manifest与bytesFetcher返回 payload 流完成两条路径check(autoDownload true)→ 轮询state直到status ready且downloaded ! null再断言安装包文件真实存在且内容与 payload 一致先check(autoDownload false)等到Available再applyAutoDownloadSetting(true)最终同样收敛到ready。测试里的 manifest 通过manifestWithCompose构造其中UpdateEngine.detectIdentity()决定dmg/msi/deb包类型artifactName(0.2.0, ...)生成真实文件名如MooTool-Next-Compose-0.2.0-mac-aarch64.dmg。四、Vault / JSON 底栏重命名钮 enabled 与操作可见性JsonVaultFooterPresentation.kt 定义了底栏纯函数fun effectivePath(vaultSelectedPath: String, currentFile: String): String vaultSelectedPath.ifBlank { currentFile } fun canRename(isDirectory: Boolean?): Boolean isDirectory false fun canShowVaultActions(path: String, isDirectory: Boolean?): Boolean showFooter(path) canRename(isDirectory)语义清晰树选中优先、其次当前打开文件只有非目录条目才允许重命名/复制底栏仅在存在有效路径时展示。此外为 Vault Git 准备了两个前置守卫gitFlushSkipsWhenClean无打开文件或文档已干净时跳过写盘 flush与gitUntitledBlockKey打开的是草稿且无 Vault 文件时返回 i18n 键git.flush.untitled阻止 Git 操作。JsonVaultFooterPresentationTest.kt 逐条断言了 effectivePath、重复/重命名仅限文件、Git flush 跳过条件与未命名草稿阻止键UI 侧则由 JsonScreen.kt 通过Modifier.mooJsonVaultFooter().mooJsonVaultFooterActions()挂载底栏按钮簇的mooJsonVaultFooterActions修饰符定义在 Controls.kt8dp 水平、4dp 垂直内边距。五、F08 / F11 / F25三个工具模块的 UI 深度接线5.1 F08 环境变量envEnvWiringPresentation.kt 提供六组可测守卫refreshEnabled(!loading !saving)、exportEnabled(hasSnapshot)、addVariableEnabled(canEdit !saving)、saveEditorEnabled(非空 key !saving)、deleteRowEnabled(canDelete !saving)、confirmDeleteEnabled(!saving)以及快照采集runSnapshot、导出写盘runWriteExportUTF-8与 diff 预览runPreviewDiff。EnvWiringPresentationTest.kt 中有一个直接验证导出链路的用例构造包含user [A1]的EnvSnapshot后调用runWriteExport(file, snapshot)断言生成文件包含A1。5.2 F11 网络工具netNetWiringPresentation.kt 把命令启动前的校验收敛成Ready / Blocked结果类型portScanStart目标与端口规格均需非空端口串交给NetEngine.parsePortSpec校验如99999越界会被Blocked拦截pingStart/resolveStart/whoisStart/ipRangeStart经normalizeHostTarget/normalizeWhoisTarget归一化后判定runCommandEnabled(idle startReady)、stopEnabled(running)、outputActionsEnabled(输出非空)flushDnsActionEnabled/refreshLocalAddressesActionEnabled仅在无在途网络任务idle时可用IPv4 与长整型互转守卫通过真实调用NetEngine.ipv4ToLong/longToIpv4判定256.0.0.1、4294967296均被拒。NetWiringPresentationTest.kt 完整覆盖上述矩阵且runLocalAddresses断言返回的 IPv4/IPv6 快照至少有一个非空。5.3 F25 硬件信息hardwareHardwareWiringPresentation.kt 提供refreshEnabled(!loading)、copyReportEnabled(!loading hasGroups)以及本条新增登记的interfacesCommandEnabled(!loading !running)——文档注明该守卫先以单测登记供后续“顶栏接口命令扩展”使用。采集通过HardwareEngine.collect(loadSampleMs)完成取消异常CancellationException不触发失败 toast。六、样式与证据CSS 组件批次 设置·更新 UI 回归帧6.1 两个新修饰符本条新增两个 Compose 样式组件对齐 Electron 选择器修饰符Electron 对应实现mooSettingsUpdateActionsRow.settings-update-actionsfillMaxWidth().heightIn(min 34.dp)见 Controls.ktmooJsonVaultFooterActionsJSON Vault 底栏按钮簇padding(horizontal 8.dp, vertical 4.dp)见 Controls.kt同时 SettingsAboutPanel.kt 的下载按钮支持注入downloadButtonModifier这正是证据帧测试用来挂焦点请求器的扩展点SettingsUpdateActionsRow内“检查 / 下载 / 取消 / 打开安装包 / 打开发布页”五个按钮的显隐分别由UpdateAboutPresentation.showDownloadAction、showCancelDownloadAction、showOpenInstallerAction等函数控制进度由UpdateProgress.percent渲染。6.2 设置·关于页证据帧SettingsAboutCaptureTest.kt 是 Compose UI 回归测试在 720×520 的画布内搭建MooThemeSettingsAboutPanel通过FocusRequester让检查/下载/打开安装包按钮分别获得焦点captureToImage()截图后统计主题强调色0x316DC0的像素数 8即认为焦点环渲染成功。三帧分别写入152-compose-settings-about-update-check-tab-focus.png、155-compose-settings-about-update-download-tab-focus.png、161-compose-settings-about-open-installer-tab-focus.png位于 next-compose/docs/evidence/2026-09-15-inspector-screencapture/windows/。DIFF-561 对应的更新帧为文档明确标注这属于“非产品主窗”的设置页证据与尚未达成的“产品主窗 Tab/IME/TCC PNG”缺口相互独立。七、验证与复现DIFF-561 列出的验证入口可归纳为三组# 1. 恢复证据 PNG ./scripts/prepare-tray-screencapture-evidence.sh # 2. 桌面测试全集JDK 21离线模式 ./gradlew :composeApp:desktopTest --offline其中 MCP 子进程用例AiIntegrationMcpHashDiffJsonQueryTest/AiIntegrationMcpTimestampUuidTest、更新流用例UpdateCoordinatorDownloadFlowTest、各 Presentation 单测ReformatWiringPresentationTest/JsonVaultFooterPresentationTest/EnvWiringPresentationTest/NetWiringPresentationTest/HardwareWiringPresentationTest与证据帧用例SettingsAboutCaptureTest均会被desktopTest任务统一执行。注意前提条件JDK 21、Compose 桌面测试环境含图形栈且需能解析依赖离线模式下使用本地 Gradle 缓存。八、未做清单看清进度的边界文档以“未做”收尾明确三块尚未关闭的实质缺口六套 CSS 逐选择器皮肤Compose 版尚未把 Electron 的每套主题选择器逐一映射产品主窗 Vault Git / IME 手工 PNG现有证据帧仅覆盖设置页等非主窗界面P7 三平台安装/公证macOS 公证与 Windows/Linux 安装包发布链路未在本条验证Vault MCP stdio 端到端扩展与其余 substantial 引擎/UI 也未包含在内目标状态parity 全达成仍为未达成。这些边界信息同样可从 next-compose/docs/feature-parity.md 与 next-compose/docs/evidence/2026-09-14-parity-gap/results.md 中追踪。结语DIFF-561 展示了一种值得借鉴的桌面应用增量开发范式每个行为都必须有对应测试或证据帧兜底每个守卫都必须能从 Presentation 纯函数单测验证。从 MCP 子进程往返、F03 格式化引擎到更新下载流、Vault 底栏与 F08/F11/F25 工具 UI再到 CSS 组件与设置页回归帧一整套“行为 → 实现 → 测试 → 证据”闭环让功能切片既可被 AI/Agent 理解也可被 CI 持续验证。对希望复刻同类工程实践、或深入 MooTool Next-Compose 源码的开发者建议从文中所列 Presentation 层文件与对应测试开始研读。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool Next Compose 开发切片解析F17/F03 引擎守卫、Vault Git remote、MCP stdio 编码与设置导航切片DIFF-560MooTool Next Compose 开发切片解析F17/F03 引擎守卫、Vault Git remote、MCP stdio 编码与设置导航切片DI桌面应用开发工具MooTool Compose 版 F03 格式化工具文件 Tab 接线与 Vault MCP 双库分页解读DIFF-572 切片MooTool Compose 版 F03 格式化工具文件 Tab 接线与 Vault MCP 双库分页解读DIFF 572 切片 DIFF 572 是 M桌面应用开发工具MooTool next-compose F03 格式化验收JVM 解析器驱动的 Nginx/Java/XML/HTML 多语言格式化实战MooTool next compose F03 格式化验收JVM 解析器驱动的 Nginx/Java/XML/HTML 多语言格式化实战 本篇围绕 MooT桌面应用开发工具上一篇Kaset高级玩法均衡器、同步歌词与智能混音三大进阶功能完整指南下一篇如何编写第一条AI元素隐藏规则以Stevos-AI-Blocklist源码为例的CSS选择器过滤列表教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考