Repository navigation
🐛 同步 compatibility_manifest: DailyWifeHelpColumn 默认值 4 -> 3 - #42
Conversation
b4cfe10 to
87fb344
Compare
上百人的群里查看老婆列表会直接刷出一大串文字,把聊天淹没;而官机(QQ 官方机器人) 不支持合并转发,原来「超过阈值走 MessageSegment.node」的做法在官机上等于没生效。 改为:条目超过 WIFE_LIST_IMAGE_THRESHOLD(5) 条时用 PIL 渲染成图片再发,未超过时 仍发纯文本,保留可复制、可搜索的好处。 - 新增 TodayWaifu/list_image.py:条目按从上到下的单列竖排,序号按显示顺序重新编号 (1→N,自上而下递增,与聊天列表读法一致);输出 JPEG 字节,渲染经 run_blocking 下沉到插件线程池。 - 视觉沿用插件内排行榜卡片的规范:背景取鸣潮角色面板图并自上而下渐深压暗(取不到 时退回淡紫渐变底),其上叠半透明白圆角卡片(alpha 112,与排行榜的 105 同量级); 标题与序号徽章用同源的「粉红(255,0,106) → 紫(106,92,255)」渐变,角色名用主题色 加粗突出。 - 卡片是半透明的,浅色背景会吃掉深色小字,故文字一律带一层白色描边,背景明暗都 压得住。 - 排版按 2 倍尺寸绘制再缩回(超采样),圆角、徽章与文字边缘才不显毛刺;条目多时 行距收紧(≥40 条用 46px),避免上百人时图片长得离谱。 - 背景是照片,PNG 无损会到近 MB,故输出 JPEG(质量 88);该图不含透明区域, 转换无损失。 - 图片消息复用既有的 _image_message():base64 编码同样在线程池内完成。 - constants.py 的 LIST_FORWARD_THRESHOLD(10) 由 WIFE_LIST_IMAGE_THRESHOLD(5) 取代, shared.py 的导出同步调整,避免两套阈值并存。 注意 _wife_list_items 返回的 items 首元素是排序用的时间戳(int(updated_at)),并不是 序号:文本版列表一直用 enumerate 重新编号,出图这一支必须照做,否则会把一串十位数字 当成序号画出来。 另外同步 tests/compatibility_manifest.json 里 DailyWifeHelpColumn 的默认值:上游 MimoKit#41 把该默认值由 4 改成 3 时漏了清单,导致 main 自身的兼容性用例失败(CI 两次红), 这里一并修正。 新增 tests/test_wife_list_image.py(11 项行为测试):0/1/5/6/31 条都能渲染出合法图片、 竖排单列(宽度不随条数变化、高度随条数显著增长)、超长名字不破坏渲染、序号按显示顺序 重新编号(且首元素不影响列宽),以及 _send_wife_list 的分支行为——超过 5 条发图片、 正好 5 条与空列表发文本;并断言旧常量与 MessageSegment.node 已不再出现。测试按 AST 加载渲染模块时同时剥掉 gsuid_core 导入并注入假字体与假资源路径,CI 上无需框架环境, 也不依赖本机角色图。 验证:pytest tests/ -q -> 378 passed(core 根与 CI 同款插件目录路径各跑一次); ruff check -> All checks passed。
87fb344 to
a47f003
Compare
- 撤回 list_image.py 与 tests/test_wife_list_image.py - daily.py / constants.py / shared.py 回到 main 的合并转发逻辑, 不保留两套阈值 - 保留 tests/compatibility_manifest.json 的同步: DailyWifeHelpColumn 默认值 4 -> 3 - 转图片后续改用其他方式实现
评审意见:转图片这条路径先不合并,但兼容性修复保留先感谢 @Xbaiyz12 的实现。排版细节做得很扎实 —— 2 倍超采样、半透明卡片配白色描边、序号按显示顺序重新编号(没用时间戳当序号)、条目多时收紧行距,这些都是对的。测试也是行为级的。 不过维护侧评估后决定先不走「转图片」这条路,三条理由: 1. 单列竖排 = 长列表会变成一张超长图这条代码里是写死的单列(
上百人的群拿到的是一张 1:7.4 的长图,被聊天窗口压缩后字号比文字版还小 —— 刷屏问题只是从「一长串文字」换成了「一张长图」。 2. 取不到角色素材时兜底背景会发灰
3. PR 描述与分支上的代码不一致描述写「按条数自适应列数(单列最多 30 行,最多 4 列)」「31 条时自动排成两列」,但分支上的实现是写死的单列竖排,没有任何列数逻辑。应该是描述写完后又改回了单列但忘了同步 —— 评审时容易误判,建议以后保持同步。 本次处理在 a47f003 之上追加 1c5b144,保留原提交与署名:
现在 PR 净改动就是那 1 行,CI 应该能绿。 后续「列表过长刷屏」这个问题会另开方式实现,方向大概率是分页 / 分段 + 文本图片混合,或者复用既有合并转发能力并对官机单独降级。欢迎继续参与讨论。 另外报告一个与本 PR 无关的问题: |
本 PR 现在做什么
只同步
tests/compatibility_manifest.json里DailyWifeHelpColumn的默认值:上游 #41 把config_default.py的默认值由 4 改成 3 时漏了这一处,导致 main 自身的兼容性用例失败、CI 连续两次红。净改动 1 行。
老婆列表转图片
原实现(commit a47f003)已在本分支撤回,改为后续用其他方式实现,评估意见见下方评论。撤回提交:1c5b144。