问题描述
感谢开发团队持续维护 Project Graph,这款工具在体积控制和操作流畅度上表现出色,令人印象深刻。
目前我注意到:
- 项目文件格式为
.prg(实际是包含 .msgpack 二进制文件的 ZIP 压缩包)
- 导出功能仅支持 SVG(渲染后的图像),不提供结构化数据的导出选项
这给用户带来了以下实际困扰:
- 无法进行版本控制:二进制格式无法用 Git 追踪变更(diff 对比失效)
- 无法进行 AI 辅助分析:无法将节点、连线、属性等结构化数据直接喂给大模型(如 Claude/ChatGPT)进行批处理或逻辑分析
- 数据迁移困难:用户无法将数据迁移到其他绘图工具(如 Mermaid.js、Obsidian Canvas、Draw.io 等)
- 无障碍使用受限:视障用户依赖纯文本解析,二进制格式无法被辅助工具读取
技术可行性
程序在运行时,内存中必然存在完整的结构化对象(节点、连线、坐标、属性、样式等),只需调用标准的序列化方法(如 JSON.stringify())即可完成导出,实现成本极低。MsgPack 的序列化/反序列化代码已经存在,反向输出 JSON 是相同量级的工作量。
建议方案
在 File > Export 菜单中,与现有 SVG 并列增加一个选项:
- Export as JSON (.json) — 纯文本格式,包含所有节点、连线、元数据
- 或至少提供 Export as GraphML / XML 等标准交换格式
如果担心 JSON 体积过大,可以提供“压缩 JSON”或“仅导出关键字段”的子选项,但核心是必须提供人类可读的纯文本结构化导出。
额外参考
GPLv3 第 1 条对“源代码”的定义是:“进行修改时首选的工作形式”(preferred form of the work for making modifications to it)。当前 MsgPack 格式作为二进制对象代码,限制了用户修改、分析、迁移作品的权利。如果项目希望继续遵循 GPL 精神,提供纯文本导出是必要的一步。
请问
- 团队是否计划在近期(如 v2.x / v3.x)增加 JSON 导出功能?
- 如果目前没有计划,主要原因是什么?(技术考量?性能?还是路线图优先级?)
感谢团队的时间和考虑!期待 Project Graph 成为一款不仅在性能上卓越,在数据自由上也同样卓越的工具。
问题描述
感谢开发团队持续维护 Project Graph,这款工具在体积控制和操作流畅度上表现出色,令人印象深刻。
目前我注意到:
.prg(实际是包含.msgpack二进制文件的 ZIP 压缩包)这给用户带来了以下实际困扰:
技术可行性
程序在运行时,内存中必然存在完整的结构化对象(节点、连线、坐标、属性、样式等),只需调用标准的序列化方法(如
JSON.stringify())即可完成导出,实现成本极低。MsgPack 的序列化/反序列化代码已经存在,反向输出 JSON 是相同量级的工作量。建议方案
在
File > Export菜单中,与现有 SVG 并列增加一个选项:如果担心 JSON 体积过大,可以提供“压缩 JSON”或“仅导出关键字段”的子选项,但核心是必须提供人类可读的纯文本结构化导出。
额外参考
GPLv3 第 1 条对“源代码”的定义是:“进行修改时首选的工作形式”(preferred form of the work for making modifications to it)。当前 MsgPack 格式作为二进制对象代码,限制了用户修改、分析、迁移作品的权利。如果项目希望继续遵循 GPL 精神,提供纯文本导出是必要的一步。
请问
感谢团队的时间和考虑!期待 Project Graph 成为一款不仅在性能上卓越,在数据自由上也同样卓越的工具。