search

rime / home

Rime::Home is home to Rime users and developers
https://rime.im
4.29k stars 233 forks source link

[功能提议]自动安装方言方案 #336

Open didntpay opened 5 years ago

didntpay commented 5 years ago

通过了解我发现使用小狼毫的方言方案，下载的方法略有瑕疵。我想了两个方案可以提升用户安装/选择体验。 方案一： 对小狼毫设定界面做出更改，将左边的列表变成二级列表。第一级显示各种方言种类像粤语，四川话，客家话这些方言的总称。而第二级列表就显示各大地区的具体方言比如像粤语-广州话，粤语-香港话, 和粤语-南宁话。在二级列表中显示出所有的方言方案包括未安装的方案，当用户选择了一个未安装的方案并按了“中”之后就可以自动下载到你设定的位置中让WeaselDeployer检测到并启用用户选择了的方案。（此解决方案仅限Windows小狼毫）。

方案二： 保留小狼毫设定界面，并通过“获取更多输入方案”启动一个我编写的GUI版installer让用户选择方言方案，然后按确定下载用户选了的方言方案去到你设定的位置，下载完后自动退出installer。此时WeaselDeployer应该会检测到用户新下载的方言方案，installer退出后用户将会在WeaselDeployer选择他想启用的方案。（此方案Windows，macOS都可以用因为installer我用java写的，甚至Linux但是因为我没有Linux系统的经验所以不太清楚）

不知道你对这个功能和我提出的两个方案认不认同，我个人觉得cmd的界面对于很多普通用户来说太过陌生，而且用户很难了解到各种方言方案的ID，用户体验可能就会相对的降低。就像issue#300里面你们探讨过的，issue#300的作者已经找到了很多超过70中方言方案，所以我觉得可能一个GUI版的installer会让用户更加想要使用。若你认同我的方案或者有任何提议，请发表你的意见，希望大家可以一起探讨一下让用户的体验变得更好。非常感谢。下面是我在方案二中提到的GUI版installer的demo，并不是final version。 demoinstaller

lotem commented 5 years ago

回顧過去，這個話題上的討論集中在以下幾點：

技術選型

須衡量：

數據的下載、升級

須實現：

數據的組織與發佈

涉及如何向安裝工具提供下載內容列表，如何組織數據文件，以及如何長期維護這個列表和數據文件。

數據文件的組織方式主要有

題主兩個方案，提出了兩種不同的介面交互設計，這個問題比較細節。我現在說不準哪種設計更合理、更易用，等實現出來再對交互做調整也不遲。

過去嘗試一些跨平臺的圖形介面技術，如 NW.js，不能很好地控制安裝使用成本：用戶表示不願爲一個設置程序而下載安裝比輸入法安裝包大很多倍的 NW.js 的運行依賴。用 bash 開發的配置管理器針對 *nix 平臺做到了較少依賴的輕量級一鍵安裝腳本，但就是由於 Windows 上需要額外安裝bash的運行環境，所以也不太成功。至於用Java開發介面，也有類似的安裝使用成本問題。各個平臺上都不預裝Java運行時。

didntpay commented 5 years ago

关于数据文件的集中收录

据我了解，很多方言方案已被issue#300的作者收录并保存了在github。是按照作者你的收录方法统一管理。 所以当数据成熟和变大之后，靠cmd的text input download对用户来说会进一步的麻烦。

关于技术选型和跨平台性

我完全同意作者你的观点，一个30-40mb大小的软件去要求用户安装200+mb的java jdk是不合理。那么我能暂时能想到的方法就是在小狼毫/鼠须管的原有程序之中去implement这个功能，这样的话就能够合理使用原有的denpendency来进一步提升用户体验。 通过google我还了解到python的script可以通过py2exe convert成exe之后不需要安装python interpreter就可以在系统上运行，至于什么系统我暂时可以确定的是windows和linux。这也是一个GUI的可能方案。

不知道作者你的意向是什么呢？

didntpay commented 5 years ago

网站下载的可能性

我发现我有点困在了client side，没有想到website的可能性。作者你认为有没有可能让rime的server收录方言方案去让用户自行下载并且帮他们保存在default folder里面。这样当他们打开小狼毫设定/鼠须管重新部署的时候作者你的程序就可以检测到方言方案然后提供用户勾选。我觉得这样比在client side重新去implement GUI界面和逻辑更为方便。作者你觉得呢？

lotem commented 5 years ago

网站下载的可能性

我发现我有点困在了client side，没有想到website的可能性。作者你认为有没有可能让rime的server收录方言方案去让用户自行下载并且帮他们保存在default folder里面。这样当他们打开小狼毫设定/鼠须管重新部署的时候作者你的程序就可以检测到方言方案然后提供用户勾选。我觉得这样比在client side重新去implement GUI界面和逻辑更为方便。作者你觉得呢？

我覺得這不就是現在小狼毫的實現嘛。用戶自行下載之後，本地就可用了。額外的GUI是無必要的。

題主您在研究了GUI的方案之後也換到了/plum/現在的實現思路上。

server： https://rime.im/download/#%E5%AE%89%E8%A3%9D%E6%9B%B4%E5%A4%9A%E8%BC%B8%E5%85%A5%E6%96%B9%E6%A1%88 其實不需要專門的server，用github就完全足夠。

如果說還要「幫他們保存到」本地的一個指定位置，這個無法從server控制，可以用到 /plum/ 的Windows啓動工具包 把要下載的github鏈接拖到快捷方式圖標上，完成「下载並保存」這一步。

laubonghaudoi commented 5 years ago

關於方案的組織

數據文件的組織方式主要有

  • 集中收錄輸入方案
  • 配方化與數據的分佈式管理

關於方案文件組織方式這個問題，我認爲經過這段時間的整理，我已經找到了一個可行的方案。即

  1. 集中收錄方案配方地址
  2. 每個配方分佈式管理

這一解決方案可以很有效地和現有的plum模式兼容。正如作者在#300中所提到的，現階段的第一步工作是方案配方化。經過這幾個月來的工作，方案的配方化已經得到較大進展。我已經和多個方案作者聯繫並請求他們把自己的方案開源在github上，且以後直接在其repo上更新方案。此回復貼末尾是我目前搜集到的方案配方地址列表。

關於下載界面的設計

讀完以上兩位的討論，我想到一個較好的解決方案是，把現有的小狼毫GUI和plum結合起來，省去命令行輸入配方地址的麻煩。小狼毫安裝包中和現在一樣，僅包含默認自帶的幾個基本方案（明月拼音等），但同時也包含已收錄所有方案的配方地址。這樣用戶可以在安裝成功後自行選擇要安裝怎麼方案，其中界面使用二級菜單對方案進行分類。我畫了一個概念圖來闡明我的想法：

微信图片_20190314150740

在小狼毫安裝包中無需自帶所有方案，只需要記錄一個列表，即下面所附的所有配方地址，即可令用戶清晰地瞭解到總共有哪些方案，並方便地選擇下載使用想要的方案。而因爲每個配方均由方案作者自己維護更新，所以這種分佈式儲存維護方式能保證用戶用到最新的方案。

我認爲這種解決方式既能和現有小狼毫的方式兼容，無需做太大改動，也能有效地提高用戶下載安裝方案的便利性，不知兩位意見如何。

已收錄配方地址：

didntpay commented 5 years ago

plum的可能方案

经过阅读作者你关于plum的建议，不知道实现这个功能的流程能否是这样。用户通过网站下载方言方案，想一个办法让plum检查浏览器默认下载文件夹，并将这些方言方案复制到输入法的文件夹中然后用户就可以选择方言方案并使用了。 就像作者你说的，网站的跨平台性始终无法比拟，如果我们可以通过改plum就可以实现三个电脑平台的自动安装方言方案可能会比我们一个一个平台的去implement不同的GUI基本上做着同样的事情更加efficent。 但是因为我没有怎么了解过bash，不知道我的提议能否实现呢？

github链接移到plum

我不太明白这个链接移到plum的意思，不知道作者能不能更加详细的解释一下呢？

lotem commented 5 years ago

@laubonghaudoi 基本同意。感謝您的不懈努力。 我希望延伸您的提議如下：

在小狼毫安裝包中無需自帶所有方案，只需要記錄一個列表，即所有配方地址

「在小狼毫安裝包中無需自帶所有方案」是目前的方向。 甚至更進一步，只自帶滿足開機體驗（指安裝輸入法之後立即開始工作）的最基本數據（minimal），包含一個精簡的拼音方案。鼠鬚管已經採用了這種打包方式。這樣做的想法是，輸入方案都是不斷更新的，勤於輸入法程序的更新，因此沒有必要讓用戶下載安裝（越來越）陳舊的數據文件。（目前還不成立，因爲配方下載和管理的功能不到位）

而配方列表，我也希望在安裝時取得最新的，畢竟要下載安裝方案就必須聯網，沒有必要打包一份陳舊的列表文件。這樣可以支持最近添加到列表的新配方，以及配方地址的變動。

再進一步，安裝包只需要包含一個URL，指向配方列表的列表，這個元配方表是相對穩定的。

我對方言拼音方案全集這個項目的期待是，最終簡化爲維護一份配方列表、並包含圍繞這個項目的流程文檔的輕量級代碼庫（不是必須的：安裝時只須下載配方列表文件，但代碼庫體量小可能方便協作，協作者能快速clone下來修改、交PR。https://github.com/rime/brise 這樣改造過，包含衆多方案的歷史記錄留在archive分支，新建了一個只維護配方列表和工具腳本的分支，最終這個新分支的代碼移到了 https://github.com/rime/plum 因爲巨大的代碼庫會拖慢其他（輸入法前端）項目的編譯。） （不是必須的：如果希望在拆分的代碼庫裏保留變更履歷還得用一組複雜的git操作如 https://github.com/rime/brise/blob/master/scripts/split-packages.sh ）

再解釋一下「配方列表的列表」的設想（尚未落實到plum的實現，下面會說到其他的現實問題和計劃）。 我認爲按照專業和興趣維護一組有共性的輸入配方，比維護一個「大一統」的窮盡式配方列表要現實。This is my feeling. 除了方言輸入方案，還可以有專注於字形輸入法的，專注於少數民族語言的，甚至只專注於一個比較窄的領域、滿足個人、小團體的興趣愛好。這種自治管理，放在整個互聯網的尺度下是比較有效的。他們只須向「元配方列表」註冊一次，而不必針對每次改動向集中式數據庫發PR。

好的GUI，除了展示各個配方列表的內容，還應提供另一個入口，允許用戶指定未收錄的配方地址，方便未登記團體做小範圍的分享測試。

我們接下來要做的是設計、規範這套流程，並開發所需的工具。 GUI在我的設想中是最後一步，否則當如何組織配方中的文件、如何獲取配方的詳細信息沒有規範的話，GUI就只能提供有限的選項，並面臨不斷修改擴充功能還要保持向前兼容的被動局面。

現實問題是bash腳本的實現目前用戶接受度不夠好，批處理腳本又比bash實現功能弱，不足以支持未來的升級。我打算忙完現在的項目（語言模型插件）之後，用「嚴肅」編程技術重寫配置管理器，保證個平臺下無依賴運行，作爲最終GUI的後端。 至於GUI，針對具體平臺開發也行，我傾向於實現一個本地webserver，借助用戶的瀏覽器做GUI，免除GUI庫的安裝依賴，或可節省開發成本，但還這個方案還沒確定。

另外，我申請了一個域名 rime.io 將來可以用作瀏覽元配方表的用戶入口。 至於網站怎樣與客戶端交互，是否可以取代GUI的部分職能，也是設計中要考慮的。

sgalal commented 5 years ago

输入方案的自动安装可以分为三个部分

输入方案收集

输入方案的作者将方案发布在 GitHub 上

运行一个 Web 服务器收集这些输入方案，并跟踪这些输入方案的变化

输入方案列表获取

客户端程序向 rime.io 指定 URL 请求输入方案列表，服务器返回 json 格式的输入方案信息。

输入方案安装

客户端程序根据请求得到的 json 列表，根据本平台的特点执行相应的操作。

例如在小狼毫中，可以

(1) 内置一个输入方案安装模块，提供输入方案选择功能，类似上述图片

输入方案选择

(2) 根据用户的选择，从 json 中获取对应的输入方案的 URL 并下载

(3) 将下载的输入方案放置在小狼毫用户文件夹中，并部署

这样做的好处是，如果需要开发一个古诗文自动标注拼音的程序，上述 (1) (2) 两步完全相同，只需将 (3) 修改为「根据下载的输入方案的词库文件，为古诗文标注拼音」即可。

didntpay commented 5 years ago

@lotem 不知道作者妳是否打算做完妳手頭的工作之後自己寫呢？還是有另外打算？

lotem commented 5 years ago

@sgalal 第三部分其實也不簡單了，最好大部分功能做成跨平臺的實現。

@ytheanswer 不慌，不慌，先做好設計。

laubonghaudoi commented 5 years ago

@lotem 客氣了，我先總結一下您的思路

關於配方列表的列表

我認爲按照專業和興趣維護一組有共性的輸入配方，比維護一個「大一統」的窮盡式配方列表要現實

除了方言輸入方案，還可以有專注於字形輸入法的，專注於少數民族語言的，甚至只專注於一個比較窄的領域、滿足個人、小團體的興趣愛好。這種自治管理，放在整個互聯網的尺度下是比較有效的

這一點我同意，但具體實現我尚不清楚。如何稱爲“有共性的輸入配方”？例如說，吳語拼音下的幾個方案，都由吳語學堂團隊維護更新，這是否就屬於維護一組有共性的輸入配方？

他們只須向「元配方列表」註冊一次，而不必針對每次改動向集中式數據庫發PR。

我尚不清楚這裏的“集中式數據庫”的意思。我那个回复的原意是，就沿用現在plum的思路，小狼毫客户端保存一个配方地址列表，直接從github抓取方案配方。因为各個方案作者直接對配方repo維護，可保證每次抓取的方案都是最新方案，這樣一來就不需要集中式數據庫了。

而關於配方列表的實現，我設想到可能會遇到以下問題：

  1. 方案配方改名。例如蘇州話的配方地址是NGLI/rime-wugniu_soutseu，但某日倉庫改名爲NGLI/wugniu_soutseu。
  2. 新增新配方。例如吳語學堂團隊新增了溫州話拼音方案，而客戶端內置的配方列表中未收錄此配方。
  3. 不僅有方言拼音方案，還有字形輸入方案、少數民族語言文字方案等等。

基於以上問題，結合您提到的利用rime.io作爲元配方表用戶入口，以及@sgalal所提出的方案，我總結出了以下的流程圖：

Untitled Diagram

這個邏輯能夠較好地解決上述前两个問題，其中小狼毫的GUI後端負責從rime.io請求方案總表和版本，前端可通過單純的點擊鼠標來查看所有方案，和安裝所選方案。至於第三個問題，我認爲只需要建立多個列表即可，即使用“記錄列表的列表“。但我尚不清楚具體實現會有何現實問題和困難，煩請三位指正。

關於方言拼音方案全集項目

我對方言拼音方案全集這個項目的期待是，最終簡化爲維護一份配方列表、並包含圍繞這個項目的流程文檔的輕量級代碼庫

请问能否详细说明一下，“包含圍繞這個項目的流程文檔的輕量級代碼庫”具体是什么。目前我的收集項目已經基本能提供一份不完整的配方總表，但這個總表應該如何維護和結合到“集中式數據庫”中，我還沒有頭緒。

關於跨平臺

我不太瞭解rime各個平臺之間的依賴關係。例如iRime和同文輸入法，是否都依賴於plum或brise的實現？

至於GUI，針對具體平臺開發也行，我傾向於實現一個本地webserver，借助用戶的瀏覽器做GUI，免除GUI庫的安裝依賴，或可節省開發成本，但還這個方案還沒確定。

我想瞭解一下，如果單純用用戶瀏覽器來做GUI會有什麼問題。如果是爲了跨平臺的話，您認爲GUI部分用electron來做如何？我沒有electron開發的相關經驗，如果提問顯得外行還請諒解。

另外，我修改了一下GUI界面的概念圖，允許用戶直接在輸入框中直接下載內測版方案：

微信图片_20190314150740
didntpay commented 5 years ago

@laubonghaudoi

整体实现

我对这个流程图和这个GUI要做的东西完全同意，特别是在拥有个跨平台的特性之后。 但是据我了解electron需要一个叫做npm的 js package manager去支持/下载electron app用了的modules。 虽然我们可以将下载这个部分隐去但是用户必须要有这个manager下载了才能确保我们app能够运行。

@lotem

关于本地web server

我不太确定这是不是你的意思，我个人对这个概念的理解是创造一个类似静态网站的 GUI page as desktop app，然后上面会有类似这样的 hyperlink https://www.google.com/去让用户去按。而这个desktop app的后端就去handle user鼠标按了哪一个link然后用bash去帮用户根据它按了的方言方案下载并deploy好。不知道是不是这个意思呢？

lotem commented 5 years ago

以上討論中對「直接按配方地址抓取文件」已經達成共識。 在我構想中並沒有rime.io「保存配方總表」「定期檢測更新」的功能。

rime.io不「保存配方總表」

我不打算讓rime.io取代「漢語方言拼音方案全集」、收集各地吳語方案的項目等等，甚至維護既有方案的「東風破」。rime.io若保存權威的「配方總表」，要求所有配方在此註冊，就成了對配方編目的「集中式管理」，其不足，僅次於對全體配方文件的集中式管理。 相反，rime.io將依存於各個項目維護的配方列表，即純粹的搬運和彙總，爲各個獨立維護的配方列表提供統一的用戶入口。即使rime.io需要爲此彙總出一個配方總表，也屬於快照的性質。而配方列表的「正本」即權威版本在各個上游項目那裏，添加和修改也必須發生在上游，所以rime.io不會接受「加入收錄總表的請求」，只會添加上游（配方列表）數據源。

rime.io不「定期檢測更新」

整個網絡中，除了客戶端，沒有任何一環必須主動獲取更新。信息的組織可以分爲三層：

其中每一層中的每個節點，都可以用一個GitHub代碼庫管理。任何修改的請求，都可以用pull request完成。每個節點都保存他所需的最少信息，即不重複下一級節點中的信息，因此完全不必定時更新，也不會出現因不及時同步導致與下級節點信息不一致。

lotem commented 5 years ago

本地webserver提供介面，類似於electron。 electron相當於自帶了webserver和瀏覽器，實現了兩者的集成，並且提供了一套開發者接口。從外面看類似native app。自帶瀏覽器的好處是不必考慮對各色瀏覽器的兼容，可以深度定製，但代價是需要增加一個瀏覽器那麼大的安裝體積。electron之前的同類項目是nw.js，我已經嘗試過了。上面也討論了爲什麼不採用這種技術。

webserver運行在本地，介面還用用戶系統上的瀏覽器呈現，缺點是只能寫兼容性好的網頁，不能實現酷炫、高仿本地應用的介面。對輸入法設置程序來說，樸素的網頁介面完全可以接受。 webserver運行在本地，重點不在於用webserver實現介面，而在於他是「本地運行的程序」。本地程序纔可以訪問本機的文件系統，而在瀏覽器裏渲染、運行的網頁和網頁腳本，都沒有訪問本地文件的能力。無論請求的是本地還是遠程的服務器，這個網頁都不能爲用戶做任何事，他只是介面，用來和用戶I/O。並不是介面來做配方的安裝。

sgalal commented 5 years ago

本地似乎不需要额外的 GUI 程序。

例如在 Windows 平台上，可以在小狼毫中内置一个配方下载与安装模块，首先从 rime.io 得到配方列表（例如 json 的形式），解析后列出配方供用户选择。

在其他平台上（例如 Android），「从 rime.io 得到 json 形式的配方列表」这一步骤不变，只需各自实现 GUI 即可。而本来各平台的输入法就自带 GUI 功能，新增一个 GUI 模块并不复杂。

laubonghaudoi commented 5 years ago

關於方案組織邏輯

根據以上討論，我總結出了修改後的流程圖，不知三位意見如何 @lotem @ytheanswer @sgalal

Untitled Diagram

說明

其中的邏輯是總共包含兩級列表。第一級列表保存於rime.io中，包括各大類型配方的總表，如：

  1. 方言拼音配方表
  2. 字形輸入配方表
  3. 少數民族語言配方表 ...

而第二級列表存在於“方言拼音全集項目”等配方收集項目中，即對各個拼音方案的收錄和組織，如：

  1. 蘇州話 NGLI/rime-wugniu_soutseu
  2. 莆田話 Yaryou/HinghuaFactory ...

因此只有在小狼毫客戶端會有“檢查更新”功能。而每次小狼毫“檢查更新”，首先會從rime.io請求獲取配方列表，然後rime.io會從各大方案收集倉庫，例如我的方言拼音全集倉庫，抓取一個配方列表，然後傳給小狼毫客戶端。也就是說，小狼毫客戶端最終獲得一個如下二級列表：

  1. 方言拼音配方表
    1. 蘇州話 NGLI/rime-wugniu_soutseu
    2. 莆田話 Yaryou/HinghuaFactory ...
  2. 字形輸入配方表 ...
  3. 少數民族語言配方表 ...

而客戶端GUI剛好可以顯示這個二級列表，令用戶總覽全部可用方案並選擇安裝，其界面設計和我上面的概念圖一樣。

問題

但這裏有一個問題，就是各大方言方案會經常更新，如何令用戶及時用到最新版方案？我能想到的解決辦法就是，讓小狼毫客戶端每次啓動時都向rime.io請求一次總表，如有更新則自動抓取一次方案。

作爲收集各配方的中間環節，各大收集項目例如我的方言拼音全集項目，除了提供所收集的配方地址列表之外，還需要做什麼工作？

關於跨平臺GUI的實現

我現在明白使用本地服務器結合瀏覽器來做GUI的意義了。但這有個問題，就是如何保證兼容各個平臺下的瀏覽器？例如有很多用戶，無論windows或mac或linux，都沒有裝chrome，甚至可能只有IE或360瀏覽器等非主流瀏覽器。但我同意直接用瀏覽器來解決方案安裝和設定是十分簡便實用的做法，只是我對於實際用戶使用體驗和兼容性仍保留疑問。

另外，我對於使用electron實現最終安裝體積大小仍然存疑，因爲一些election應用例如discord，其安裝包大小僅不到60MB，對於一個輸入法程序，安裝包大小有多少才是用戶可接受的範圍？

lotem commented 5 years ago

基本的網頁介面可以兼容各種瀏覽器。預計與用戶的交互並不複雜。 如果用不到自帶webkit提供的專有功能，那就沒有必要用electron顯示標準的網頁而不利用系統瀏覽器。

比較一下僅打包最精簡的拼音輸入方案的鼠鬚管安裝包： https://bintray.com/rime/squirrel/release Squirrel-0.11.0.zip Size: 4.5 MB 這是一個工具軟件比較理想的狀態。以後還會再增加一些東西，但是爲了提供設置介面而增加數倍大小就不合算了，用戶只會認爲這個輸入法很大。假如必須採用這種實現，我主張設置程序獨立發行。

針對「問題」： 用戶打開設置程序主動更新時，肯定是獲取最新的列表。 但輸入法在後臺自動更新，我認爲對大多數用戶都不必要，更新和部署的時機也不好確定。比起自動更新（類似的還有自動同步用戶詞典）帶來的方便，下載更新文件和重新部署過程（以及可能產生錯誤）干擾用戶輸入是更嚴重的問題。給一個「～有新版本」的提示，讓用戶在方便的時候自主更新比較穩妥。

laubonghaudoi commented 5 years ago

那是否在小狼毫之中加入一個手動檢查更新的功能，會更加現實？每次手動檢查更新的時候，向rime.io請求方案總表，得到所有方案的配方地址及版本，然後再選擇更新方案。

關於使用瀏覽器来做方案選擇介面的辦法，我認為值得一試。

另外，對於修改後的流程圖，三位的意見如何？對於此二級列表的邏輯有無其他問題？@sgalal @ytheanswer @lotem 我比較關心我的方言拼音輸入項目中所需要實現的『輕量級代碼庫』具體工作是甚麼。

sgalal commented 5 years ago

我不太明白爲什麼需要額外實現一個跨平臺的程序。

比如，當用戶在小狼毫中選擇方案總表中的 biopolyhedron/rime-zhuyin 後，小狼毫下載 詞庫文件 和 方案文件 兩個文件，放置在 【小狼毫】用戶文件夾 中，並部署即可。

當用戶在同文輸入法中選擇同樣的方案時，同文輸入法下載同樣的兩個文件，放置在 同文輸入法的用戶文件夾 中，並部署即可。

在這一過程中，只有「用戶選擇方案總表中的某一方案」需要使用 GUI。

所以我認爲，各平臺的輸入法似乎可以根據各自平臺的特點，在程序中各自加入方案選擇和下載模塊。

lotem commented 5 years ago

@sgalal 可以。 如果有足夠人力，前端項目可以自己實現這個下載安裝流程，用戶體驗會更「原生」。

我在以上討論中考慮的是爲開發資源不足的各平臺前端提供一個便宜的通用解決方案。 而且只考慮在電腦上使用。我覺得這些放在移動端做太吃力了，不如在電腦上部署完再同步過去。

只要先制定好流程，大家可以根據自己的興趣嘗試不同的實現，並行不悖。

laubonghaudoi commented 5 years ago

@sgalal @lotem 我認爲無需考慮移動端的方案安裝問題。以iOS平臺的iRime輸入法爲例，目前已經有選擇方案直接下載安裝的功能，iRime的作者也開了一個倉庫，專用於預置其雲方案。這相當於採用了集中式方案管理，如果有新的方案或者原有方案更新，都要向這個倉庫pull request。而我之前曾聯繫過同文輸入法的作者，可能也會採用此種方法。因此目前來看，我以上總結的流程圖均只考慮桌面平臺，移動端另行單獨考慮。

另外，如果我們沒有足夠的人力，但沒有時間限制，是否也應該爲了更好的用戶體驗而開發原生的界面？無需一次性全部完成，可以先從用戶數量最大的windows開始，再到mac，最後linux

laubonghaudoi commented 5 years ago

@lotem 另外我想請問一下，本帖中所提到的語言模型插件目前開發進度如何？我想向其貢獻，請問是否有相關issue或pull request供我先了解一下情況？非常感謝。

laubonghaudoi commented 4 years ago

@shenlebantongying 太好了，謝謝你的貢獻。現在收錄的方案還是比較少，收錄好後還要再整理分類好。另外我的網站 https://sinolect.netlify.app/ 因為個人繁忙現在已經廢棄，希望能有人接手。