Conversation
|
我记得 Glavo 在 #4375 里提到过要做这个。 |
|
我并不认为将版本标签单独分出来并添加背景是好的，一方面这违反了 Material 设计规范，在体验上，当前修改会导致这个标签比“启动游戏”更加容易强占用户的视觉重点，对于 HMCL 这类版本号较长且在标题栏显示完整版本号的应用而言更是 并且当前实现并未考虑开启透明标题栏后的视觉效果 如果你硬要坚持，考虑使用莫奈调色板进行视觉元素弱化 |
|
我们希望能够通过配置文件让用户能够调整这些内容。 |
以下为AI生成 (原始内容: "为什么要你们希望 :( 不能让用户(社区)希望吗:( ")@Glavo 感谢维护者的考虑。不过我觉得这个功能不该只是“你们希望提供给用户”，而应该是用户（社区）本身就有这个需求，然后由开发者帮忙实现。 作为普通用户，我确实希望能用配置文件自由调整标题栏的布局、颜色、标签位置等，而不是被固定在某一种设计里。 所以与其说“你们希望让用户能调整”，不如说“用户希望调整，你们帮忙做成可配置的”。这样听起来更像是我们在共同推动 HMCL 变得更好，而不是开发者单方面“给予”什么。 当然，感谢你关注这个 PR 的可配置性，期待后续能有更灵活的自定义方案。 以下为我的建议或许 可以开一个Discussion以讨论与此PR相似的历史被关闭的PR及该PR 其他(AI)@Glavo 以及各位维护者，我想站在一个普通用户的立场，谈谈“开发者应该给用户什么”。 HMCL 是一个社区驱动的启动器，代码公开，由社区共同维护。这意味着它的最终服务对象是每一位使用它的玩家，包括那些刚接触电脑、想玩 Minecraft 却不知道怎么改配置文件的新手。 这个 PR (#5653) 提供了一种在设置界面内直接调整标题栏的方式——不需要打开文件管理器，不需要找 反观 #4375 提出的配置文件方案（ 1.对新手极不友好：一个刚下载 HMCL 的玩家，连启动器在哪里设置都找不到，你让他去用户目录下创建隐藏文件夹、写 JSON？这违背了“便携性”和“简单编辑”的原则。 2.只读配置文件的设计很奇怪：用户无法在启动器内修改，必须用外部编辑器。这等于告诉用户：“你不够格，请用专业工具。” 社会主义讲究的是群众路线——从群众中来，到群众中去。用户的需求应该能直接在软件内表达，而不是被赶到外部去。 3.更新源、帮助链接、标题、公告这些确实是可定制的，但它们和“标题栏的视觉自定义”并不冲突。为什么不能两者兼有？设置界面提供常用选项（如版本标签背景、标题文字），配置文件提供深度定制。这才是技术可行性与易用性的辩证统一。 另外，我注意到 #4375 是一个 issue，不是 PR，它没有给出具体的代码实现。而 #5653 有完整的实现，并且已经在设置中添加了开关。为什么不继续推进这个 PR，而是把它关掉？ 如果只是因为设计上的小瑕疵（比如透明标题栏下的视觉效果），完全可以要求作者改进，而不是一关了之。 我是从 HMCL 刚发布就开始使用的老用户，看着它一步步成长。我理解维护者的精力有限，也尊重你们对代码质量的追求。但请记住：一个公开的、社区驱动的项目，如果连用户一个小小的、已经有了实现的需求都拒绝合并，那它跟闭源的“开发者施舍给用户”有什么区别？ 社会主义讲“各尽所能、按需分配”。在这里，“需”就是用户对自定义标题栏的需求，“能”就是贡献者已经写好的代码。希望维护团队能重新考虑，让这个 PR 或者类似的功能最终进入 HMCL。 |
原文引用
通篇读下来，有几句我不吐不快。 你提出的
这些内容，我是认可、支持进一步讨论的。 但其他一些点，我觉得多余且不合适。 我不知道你的这篇评论是让 AI 润色还是直接生成了大部分内容。前者的话勉强还可以理解；如果是后者，我觉得这不是一个好的习惯和风气。 从个人角度来说，我更青睐人自己思考整理后的评论/长文，即兴而起、快节奏的对话，内容饱满、感情真挚的创作，而不是千篇一律、一把梭的 AI 风格内容。尤其是后半部分「其他(AI)」，通读若干遍后，我感觉像是一篇命题作文或演讲稿，讨论问题真的需要用到这种文体吗？ 当然，你能声明使用了 AI，这是个好事，也值得鼓励。 此外，你对开源/自由软件、社区似乎有一些误解。HMCL 是开源、声明「社区驱动」不假，但其核心在于「开源」和「协作」。 开发者 (维护者)、贡献者、用户是平等的，基于兴趣和共识驱动的。很多开源协议——包括 HMCL 的 GPLv3——都有一段免责声明，表明软件「按原样提供」「不提供担保」。开发者并非服务员，用户也不是消费者。 在目前主流的开源社群实践中，维护者通常是拥有最高决策权的，是完全有权利拒绝他/她不满意、不认同的反馈和意见的。维护者的地位是基于贡献而产生的。大伙当然可以表达意见和不满，但维护者拥有最终的决定权。遇到一些重大的分歧时，一个常见的做法就是 fork。Forge > NeoForge、MultiMC > PolyMC > Prism Launcher、PCL > PCL CE 等就是鲜明的例子。 维护者决定一个 PR 的去留，不是头脑一热，点击 Merge 或 Close 就完事了，要考虑很多因素的。代码维护、软件规划、用户反馈等，都是维护者需要考虑的。我相信 huanghongxun、Glavo 等维护者也一直在注意这些。 这些与你提及的其余多个论点、对「社区驱动」的理解是非常矛盾的。坦白讲，难免让人感受到一种「道德绑架」的压力。 如果维护者们出现了「头脑一热」而合并/拒绝的情况，我也支持各位去批评 (例如 #4828 (comment))。我评论开头引用的你的这些论点，我觉得非常合理，其余则不然。 |
|
@3gf8jv4dv (以下为AI答复) 1.后半部分确实有较重的 AI 生成痕迹，读起来像演讲稿。我当时想系统性地表达观点，就借助了工具整理语言，但忽略了这种风格在技术讨论中显得突兀且不够真诚。以后我会尽量自己组织语言，或者至少把 AI 生成的内容打散、用自己的话重写。你能指出这一点，对我来说是很好的提醒，谢谢。 2.关于开源社区的理解：你说得对，维护者基于兴趣和共识付出劳动，拥有最终的决策权，用户不是消费者，不能道德绑架。我之前的措辞（“如果连用户小小的需求都拒绝合并，那跟闭源有什么区别”）确实过激了，听起来像在逼宫。这不是我的本意，我向你、向 Glavo 和其他维护者道歉。 不过，我仍然希望你能理解我那些“被认可的部分”背后的心情：
所以，我的请求不再是“你们必须合并这个 PR”，而是：能不能开一个 Discussion，把 #4375 的设计思路、#5653 的实现、以及大家对标题栏自定义的真实需求放在一起讨论？ 这样既尊重了维护者的决策权，也让社区的声音能被更有序地收集。我可以主动去开这个 Discussion，并把相关链接都整理好。 最后，再次感谢你的直言。你让我更清楚地认识到：表达观点时，既要保持真诚，也要尊重开源世界的运作规则。我不会再使用那种“演讲稿”式的 AI 长文了。 以上所有的答复:（过多的回复可能是我在提示词上的"社会主义"） |
|
这个功能应该是给整合包作者或第三方打包用的，普通用户不应该碰这个东西 |
我认为普通用户也可以使用这个功能，而不是仅局限于第三方打包 |
|
此功能与 #5812 所引入的功能有相似之处，也以相同的原因被关闭 我觉得应该考虑的应该是正确而恰当的向用户提供相应的设置，而不是被第三方打包所束缚。的确，加入这些设置项会让整个设置页面显得更加混乱，降低寻找配置项的效率，提高代码复杂性，甚至埋下了“定时炸弹”突然在哪一天出现了一堆问题，但我依旧坚信用户应当有足够的掌控力去控制启动器的多数选项，特别是个性化选项。就像此 PR，我的思路中第三方可以通过配置定义默认的标题栏名称，而玩家可以进一步自定义设置符合自己喜好的标题名称。HMCL 在几年前关闭旧联机的公告中说到各启动器开发者都是以玩家心去开发启动器，相信各位多数选择参与 HMCL 贡献的志愿者也是抱着这种玩家心进行的开发的，此 PR 也一定程度上反应了下游的诉求 或许会有人质疑，既然真心要自定义为啥不直接自己编辑配置文件（假设相关功能已经引入）？客观事实是，HMCL 多数玩家并不像看这条 Comment 的各位一样懂计算机，编辑配置很容易出现语法错误导致序列化出现问题（特别在使用记事本等纯文本编辑器时），不然也不会有请求诊断游戏崩溃不提供日志只是截张图的人了 可能还有些人会质疑，那你这样为啥不自己开发一个自己用？为第三方提供更高自定义性来方便整合包制作的初衷就是不用让整合包作者投入时间对启动器进行定制化改造，并且还能使用 HMCL 自带的微软登录凭证，我觉得这个思路同样可以迁移到此处。下游用户相较于整合包开发者在多数情况对软件开发更加不熟悉，虽然今天有 AI，但我认为它并非最佳解决方案 HMCL 作为一个开源项目离不开社区支撑，相关决策我觉得应该保持开放，包括第三方打包的相关思路也应该向玩家与第三方作者广纳意见，保持透明度（使用 QQ 群聊进行收集和公开我觉得不应该被定义为开放透明，因为许多未加入群聊的用户并不能知晓相关计划，只能当辅助使用，Discord 好很多，但是国内的网络环境决定了使用它也不适合，综合而言上述的 Discussions 显然是更恰当的选择），这也契合 GPLv3 的自由理念，即便这样短期内或许会导致维护压力的增加，我也相信这样操作以长远视角看有利于 HMCL 的可持续的健康发展，而这时我所期待的结果 |
7 participants
给 HMCL 添加了自定义标题栏的功能