- 15 Apr, 2026 6 commits
-
-
之前只有两个图标并排, 用户看不出来要拖拽. 现在在 DMG 挂载打开时: - 中间一根灰箭头从 .app 指向 Applications - 底部中文提示 "将左侧应用拖到右侧 Applications 即完成安装" - 窗口/图标/箭头三者坐标对齐 实现: - 用 PIL 在 staging 阶段生成 600x400 PNG, 放 .background/bg.png (dot 前缀让 Finder 默认隐藏) - AppleScript 里 set background picture 用 HFS path (冒号分隔) - 图标位置 {150,200} / {450,200} 与背景图箭头两端对齐 PIL 字体查找: PingFang (默认中文) -> STHeiti -> Helvetica -> 兜底, 在打包机上都会命中至少一个. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>柴进 committed -
双击挂载后, Finder 窗口显示两个图标并排, 用户直接把 ZB100ImageGenerator.app 拖到 Applications 快捷方式上即可安装, 不用讲解路径, 符合 macOS 标准分发体验. 实现: - 先 staging: 把 .app 放入临时目录, 同级建 Applications 软链 - hdiutil create UDRW 可写镜像 - 挂载 -> AppleScript 设置窗口大小/图标位置/视图样式 - 卸载 -> hdiutil convert UDZO 压缩成只读分发包 - osascript 失败不中断 (防 Finder 自动化权限未授予), DMG 仍可用 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
背景: lehe 机器启动崩是因为 SMB 传输吃掉了 PIL/.dylibs -> __dot__dylibs 内层 symlink, 导致 libtiff dlopen 断链. 修复: 构建脚本新增 hdiutil create 步骤打包 DMG (UDZO 压缩). DMG 是 HFS+ 镜像, symlink 完整保留, 用户挂载 -> 拖拽到 Applications 即用. 以后发 DMG, 不要直接拷贝 .app 目录. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
lehe 那台 macOS 26 新包仍崩, 诊断发现不是打包问题: Frameworks/libtiff.6.dylib -> PIL/.dylibs/libtiff.6.dylib (broken) PyInstaller 6.x 实际结构: PIL/__dot__dylibs/ <真目录> PIL/.dylibs -> __dot__dylibs <内层 symlink, 被 NAS 吃掉了> Frameworks/libtiff.6.dylib -> PIL/.dylibs/libtiff.6.dylib <外层 symlink> 内层 symlink 丢失 → 整条链断. 其他 macOS 26 机器能跑是因为挂载 NAS 的协议/客户端不同, 保 symlink. 记进 spec 注释, 下次再有人打包踩这坑直接看到结论. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
上一版 spec (4097b529) 在 macOS 26 构建出的包仍崩在同一位置: dlopen: Library not loaded: @rpath/libtiff.6.dylib 修改: - 引入 PyInstaller 官方 collect_dynamic_libs('PIL', destdir='.') 作为主策略, 显式枚举 .dylibs/.libs 作为兜底 - 每步打印详细信息: PIL 安装路径、找到的文件列表、 最终 binaries 合并结果 - 最后如果 len == 0 直接打印警告, 免得构建成功但运行时才崩 下次构建输出里找 [spec] 开头的行, 就能看清是哪步出了问题: - collect_dynamic_libs 返回空? -> PIL 没 bundled dylibs - .dylibs/ 不存在? -> Pillow 装的不是 wheel - 有文件但 bundle 里没有? -> PyInstaller 传入后续处理的问题 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
构建流程 (修复 macOS 26 上 libtiff.6.dylib 未打包闪退): - ZB100ImageGenerator.spec 成为跨平台构建配置唯一真相源 - 显式枚举 PIL/.dylibs/.libs 下的原生库并平铺到 bundle 根目录, 匹配 PyInstaller 把 _imaging.so 的 @rpath 改写成 @loader_path/.. (= Contents/Frameworks/) 的预期位置 - build_mac_universal.sh / build_windows.bat 不再删除 *.spec, 调用简化为 `pyinstaller ZB100ImageGenerator.spec` - 旧的 --collect-all PIL 方案保留了 .dylibs/ 目录结构, 跟 rpath 预期位置不匹配, 治标不治本 诊断日志 (定位 refresh_history 的 SIGKILL 位置): - 新增 _flush_logs() 模块级工具, 在可疑阶段边界强制刷盘 - load_history_index: 每 20 条打一次路径修正进度 - refresh_history: clear/load/loop 三段独立计时, 每 20 条打渲染进度 - 下次 macOS 卡死被 SIGKILL 时能精确定位死亡行 昨天 138ec9fa 的 thumb.jpg 缓存挡住了内存压力型 SIGKILL, 但今天 115 条时 refresh_history 仍卡 8 秒后被 WindowServer 强杀 (日志 只打了 "开始刷新" 就再无输出). 真正的架构修复 (取消 clear+rebuild 全量重绘) 留待下次定位清楚后再做. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed
-
- 14 Apr, 2026 2 commits
-
-
根因: - refresh_history 每次调用都 history_list.clear() + 重建全部条目 - 每条加载 2K PNG 原图做 QPixmap (~16MB 解码) 再缩到 120x120 - 106 条历史 × 16MB = ~1.7GB 瞬时内存峰值 - macOS 内存压力触发 SIGKILL，不可被 faulthandler 捕获 - 日志里只有 "开始刷新" 没有 "加载到 N 条"，确认死在 clear()/load 之间 修复: - HistoryManager 新增 thumb_path_for + get_or_create_thumbnail: 用 PIL 生成 240x240 JPEG 缓存到 <record_dir>/thumb.jpg, 基于 mtime 判断是否重新生成 - save_generation 保存原图后顺便生成缩略图 (失败不影响主流程) - refresh_history 只加载 thumb.jpg, 内存峰值从 1.7GB → 6MB (280x 下降) - 缩略图生成失败用占位图兜底, 不回退加载原图 (防回到危险路径) - 首次升级会为 106 条存量一次性补生成 thumb.jpg (PIL 串行 ~32MB 峰值, 安全) 附加: - refresh_history 增加 "刷新完成" 收尾日志, 便于下次若再崩定位死亡位置 跨平台: 纯 PIL + pathlib + Qt 标准 API, Windows 零回归 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
粘贴闪退 (macOS 26): - _safe_get_clipboard_image 在 Darwin 上禁用 mimeData.imageData() / clipboard.image() / application/x-qt-image 三条 native crash 路径， 统一走 image/* 原始字节 + osascript PNGf 兜底 - DragDropScrollArea.dropEvent 的拖入图像分支同步做平台分流 - Windows/Linux 路径完全保留，零回归 长时间运行闪退: - init_logging 改用 RotatingFileHandler (5MB × 5)，避免日志无限增长 - 启动时清理超过 24 小时的 clipboard_*.png 遗留临时文件 Gemini 返回空图片: - response_modalities 加上 TEXT，允许模型回传拒绝理由 - response.parts 增加 None 保护，修复日志里 20+ 次 'NoneType object is not iterable' 异常 - 错误上浮 finish_reason + 模型说明到 QMessageBox 缩略图拖拽重排: - 新增 DraggableThumbnail + THUMB_REORDER_MIME 内部协议 - 缩略图可拖动调整顺序，reorder_image 正确处理左右移动的索引 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed
-
- 19 Mar, 2026 3 commits
-
-
根因: PIL/_imaging.so 依赖 libtiff.6.dylib，但 PyInstaller 默认未收集。 修复: 添加 --collect-all PIL 确保所有 Pillow 原生库(.dylib/.so)被打包。 同步更新 Windows 打包脚本。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
build_mac_universal.sh 是严格超集：自动检测架构、自动安装依赖、错误处理更完善。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed -
- faulthandler: segfault 时自动输出 Python 调用栈到 crash_log.txt - 全局 sys.excepthook 捕获未处理异常 - Qt 消息拦截器捕获 QtWarning/Critical/Fatal - 启动阶段打桩 [BOOT Phase 0~8] - 主窗口初始化打桩 [INIT 1/6~6/6] - QImage.save 崩溃高发点前后日志 - 系统环境信息记录（OS/Python/Qt/Pillow 版本） Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
柴进 committed
-
- 02 Mar, 2026 1 commit
-
-
柴进 committed
-
- 28 Feb, 2026 9 commits
- 27 Feb, 2026 2 commits
- 15 Jan, 2026 1 commit
-
-
柴进 committed
-
- 13 Jan, 2026 2 commits
- 18 Dec, 2025 2 commits
- 12 Dec, 2025 2 commits
- 11 Dec, 2025 9 commits
- 10 Dec, 2025 1 commit
-
