【功能提议】提供输入方案选择和下载的GUI界面

[laubonghaudoi]

小狼毫作者你好，我是Rime汉语方言拼音输入方案收集项目的作者。
我最近收到比较多求助，关于如何添加使用我收集的方言拼音输入方案。尽管我准备写一篇教程来手把手教新用户如何通过复制.yaml文件和修改default.custom.yaml来实现方案添加，但我认为这不是长久之计。另外通过打开“方案選單設定->獲取更多輸入方案”的添加方式，因为命令行界面对于新人太陌生，且无法知道各个方案的ID，也聊胜于无。因此我希望小狼毫能在右键菜单中加入一项“方案选择”，点击后出现一个GUI选择界面，上有服务器已收录的全部输入方案（我可以提供我项目中所收集的全部方案），点击即可下载添加，若能实现，可显著帮助推广方言拼音输入。非常感谢。

[lotem]

現在缺個編程的。圖形介面一時半會做不出來。
可能路徑是：配置管理器 > 現有輸入方案的配方化 > 配置基礎配方及常用定製項目的配方化 > 升級配置管理器 > web介面，現在處於第二步。

實現選擇下載方案的先決條件是把輸入方案打包成配方。建議你先做這項工作。
參考：
https://github.com/rime/plum
https://github.com/biopolyhedron/rime_schemata
https://github.com/lotem/rime-forge

[laubonghaudoi]

感谢你的指示，因为我没有打包输入方案配方的相关经验，我在看了链接里的文档后仍有一些疑问：打包成配方的工作具体是否自己编写对应的.conf和.bat文件？打包成配方后的方案的文件形式是什么？我应该怎样提交打包后的配方到服务器，令用户可以直接在命令行下载安装？

补充：在参考了这个issue之后，我的理解是，每一个配方就是其对应的.schema.yaml和.dict.yaml文件，那么应该如何实现配方打包？

[lotem]

严格来说应该有个配方定义文件，但目前这套工具还不成熟，我把典型的输入方案+词典文件的配方简化为：
用单个 GitHub 代码库，.schema.yaml 和 .dict.yaml 文件放在顶层目录，可选地提供一个 README.md 可以套用 模板
实例： https://github.com/rime/plum#phonetic-based-input-methods 这里随便点一个连接就是一个输入方案配方包。
这个代码库地址的 用户名/项目名 就是配方的唯一标识，可以用来下载输入方案。

所以你得先把代码库拆开。按内容分成单独的代码库。
现在这种组织方式一是将来不利于管理，他依赖于大家都往一个中心代码库提交文件，但 Rime 允许用户自由定制，无法强化某个发布渠道的权威性，所以永远都是收不全的、无法保证更新的。
二是用户没办法按需要下载，这对提高下载速度、提升安装体验非常重要。

这样改造后，仍可以收集方案，但只要列出配方就可以了，不用维护一个庞大的代码库。
实例： https://github.com/biopolyhedron/rime_schemata
.conf 和 .bat 是临时的配方列表格式，在服务器上开店之前代用。

配方列表优先收录原作者或方案维护者的配方地址，以保证能自动获得最新版本。

[laubonghaudoi]

感谢你的详细说明，也就是说，我现在有两种方案：

1. 把我收集项目中的所有方案都单独拆分成一个Repo，格式同luna-pinyin，然后提交至 https://github.com/rime 下。例如要打包上古全拼方案，即创建 https://github.com/rime/dkzp 这一单独Repo，然后安装上古全拼时直接在Rime Package Installer命令行输入dkzp即可。
2. 参考rime_schemata，将我的收集项目改造成一个总列表，编写.conf和.sh文件作为列表索引，直接导引至方案作者下的Repo实现实时更新，用户也可以一次安装多个方案。

不过我还不明白的是，为什么说第一种方案“用户没办法按需要下载”？事实上我的设想正是确立一个权威的统一发布渠道，令普通用户可以傻瓜化地即装即用，因为普通用户无需考虑也没有对应的编程能力来自定义方案。我认为“永远收不全，无法保证更新”不是一个需要担心的问题，因为对于普通用户来说“即装即用、无繁琐配置”才是最重要的特点。而且一般情况下方言拼音方案只会在启用初期会有小修补，一旦确定普及后都不会有修改，就如普通话拼音方案已经沿用几十年不变。如果方案作者对其方案有更新，我可以和他主动联系并手动更新Repo来实现方案更新。

至于第二种方案，我尚不明白和第一种有什么区别，因为似乎都是要单独为每个方案新开一个Repo，只是可以一次预装多个方案而已。因为普通用户一般只需安装一两个方案，即自己的母语方言，无需同时使用多个方案，所以我觉得不太重要。而直连作者方案Repo实现实时更新也意义不大，因为我收集项目中的方案有超过一半不来源于github，且一部分已经绝版即来源不可考（例如已过期的百度网盘链接、qq群文件等），此类方案不会有任何更新，只能直接新建一个Repo作为永久方案保存地址。如上一段所说，对于不在github上的方案，我统一联系作者代理更新这样似乎更现实可行。

所以目前来看，如果使用第一种方案，小狼毫只需要预装最常见的依赖项如luna-pinyin等，然后我在教程里列出所有方案的schema-id，用户即可在“方案選單設定->獲取更多輸入方案”中输入shcema-id安装方案，这是我目前想到的最方便的做法。不知阁下意见如何。

[lotem]

并没有两种方案。
代码库拆分后，不需要转移到 github.com/rime 这个组织名下。luna_pinyin 这组方案因为是 Rime 团队开发和维护的，所以放在这个组织账户。其他账户的配方包只要加上前缀 GitHub用户名/ 即可使用。
我倾向于代码库托管于原作者或当前维护者的账户，这样通过配方可以知道方案从哪里来，在哪里能找到最新的源代码；而且其他用户 fork 代码库之后，就自动地有了一个新的配方标识 另一个用户/方案名，用家可以很方便地选择安装原版还是衍生的修改版，不存在“中心repo该收录哪个版本”的问题。
git 提倡去中心化，这样对用户和开发者都是最方便的：
输入方案开发者在 GitHub 创建一个代码库，便立即对所有用户可用，不需要任何申请、等待中心收录的步骤。事实上，如果存在一个“中心”，很多开发者会满足于“现在终于能用了”，懒于或没有意识要去申请“中心”收录。这就是我说“收录不全”的原因。
用户只需（无论通过任何渠道）获知配方，就可以下载安装；不限于“中心”收录的可供自动安装的方案。
如果用户想对方案做些改动，可以 fork 代码库保存自己的修改，不必依赖于原作者同意更新代码。
计划中的"官方”收录的方案列表，只是提供一个分享信息的平台。任何人都可以维护并发布这样一个列表，比如专门针对某一类方案的。如果配方（代码库）的格式规范了，收录配方的工作将来也许可以由程序通过在 GitHub 上搜索代码自动完成。

你可以做维护者，替原作者维护某些方案，但请了解原作者不是唯一与此有关的人，随时可能有人在开源的代码基础上做出改进，他们也许不会把这些改动合并到你的代码库。如果你复制了一份代码而不是维护着一份“绝版”方案，那么他人也有可能在原作基础上改进从而衍生为不同的分支，所以说在 GitHub 上集中维护所有方案的最新版是无法操作的。
将各种来源的代码复制到一个代码库里，这其实是为这些方案创建了一个收录时的“快照”。

至于要按方案拆分代码库，是因为以 git clone 方式获取代码比较方便，这是现在配置管理器的实现。
从一个包含众多方案的代码库里单独下载某些文件当然也是可行的，不过不能简单地 git clone 整个代码库，而且这么做就必须为每个方案提供一个“配方描述文件”列出要下载的 YAML 文件。

[laubonghaudoi]

我明白你的意思了，其实我的观点就是，我并不需要考虑“用户自行改动方案，fork代码库保存自己修改”的这种情况。因为我的目的是为用户提供一个傻瓜式即装即用的解决方案，此类用户的共同点是“不会编程、不会用Github、畏惧使用命令行、想通过点击鼠标就解决全部问题”，所以此类用户不会自定义方案，我也不需要考虑方案有衍生版，我只需要确保与每个方案的原作者保持充分沟通，确定集中提供下载的配方是最新版就可以了。也就是说我的收录中心只收录原作者的“权威版”方案，不收录任何经过其他人二次修改的衍生版本。这并非禁止用户自行修改，对于有能力自定义方案的“硬核”用户，他们始终可以任意修改发布自己的版本。

另外对于目前Rime Package Installer的工作原理我还不是很了解，为什么我在安装jyutping这些在github.com/rime组织名下的方案，就不需要写作者名，直接输入jyutping就能自动识别安装，但是对于不再rime组织名下的方案例如https://github.com/Kahaani/dieghv 就必须加入作者名输入Kahaani/diegv才能安装。这样的话，是不是把所有方案都转到rime下会更方便用户安装？虽然我可以在教程下把所有的安装命令列出，但这毕竟增加了用户的困惑度和学习成本，因为输入dieghv比输入Kahaani/diegv要简单易懂得多。还有我有时在安装了一个方案之后，再安装第二个会要求输入github帐号密码，这是不是程序的bug？

由于我认为单独为每个方案新建一个Repo的做法不合适，同时维护几十个Repo也过于混乱不现实，所以我目前的推测是，我应该在我的收集项目下编写对应的.conf和.bat文件，然后在教程中指导用户输入对应的id来安装。

[lotem]

多输入几个字，在便利性和学习成本上没有太大差别。
如果感到迷惑，可以一律把配方写全，比如把 jyutping 改为 rime/rime-jyutping 。省略前缀的形式请把它当作兼容早期版本的措施：开始制作这个工具的时候视野狭窄、考虑不周，后来已经有用户用了简写才发现需要带上用户名才有可能做到全网通用。

我对用家有各自的看法和喜好有充分理解。这也印证了一套通行的解决方案实现上有多么困难。
很遗憾目前的配置管理器还不能很好地支持你所希望的用法。这当然不是说没有办法做到，只是你需要多写一些脚本程序来支持这种代码管理的方式，若能更进一步实现一个专用的图形化界面就更好了。有成熟的想法就去尝试吧。