[功能問題回報] 安裝時遇到的問題

[xareelee]

摘要

是在安裝上的問題，有兩個問題

1. homebrew 版本沒有更新，目前 GitHub 上 tag 是 2.2.1，但 homebrew 上是 2.0.1。若是不再提供 brew 安裝，建議在文件上說明。若支援 brew 安裝，則建議加入 CI 機制自動發佈。

$ brew info mcbopomofo 
mcbopomofo: 2.0.1

2. 手動下載連結，被 Chrome 瀏覽器判定為危險檔案 (McBo....zip is not commonly downloaded and ma be dangerous)，不確定原因為何。我的下載路徑:

https://github.com/openvanilla/McBopomofo/releases/download/2.2.1/McBopomofo-Installer-2.2.1.zip

快速分類
請問您遇到的是：

• 其他: 安裝時的問題

預期正常狀況

建議在 README.md 中加入安裝指引的說明連結，並說明可能會遭遇的問題。

電腦環境
請問您在怎樣的環境遇到這個問題？

• macOS 版本：11.6.4
• 在哪個應用程式中打字遇到問題：N/A
• 電腦機種：Intel
• 其他特殊設備：N/A
• 特殊設定：N/A

其他
其他你覺得問題發生的疑點，或其他想跟小麥開發者說的話。

[lukhnos]

謝謝你的問題回報：

homebrew 版本沒有更新，目前 GitHub 上 tag 是 2.2.1，但 homebrew 上是 2.0.1。若是不再提供 brew 安裝，建議在文件上說明。若支援 brew 安裝，則建議加入 CI 機制自動發佈。

我們幾個開發者並沒有提供資訊給 homebrew-cask。根據 PR 紀錄，小麥的套件資訊是社群提供的: https://github.com/Homebrew/homebrew-cask/pulls?q=is%3Apr+mcbopomofo

事實上，小麥甚至還有社群提供的 MacPorts 安裝資訊…

我個人對於社群維護套件資訊，多一個安裝管道，樂見其成。

若支援 brew 安裝，則建議加入 CI 機制自動發佈。

有任何相關文件可以參考嗎？

手動下載連結，被 Chrome 瀏覽器判定為危險檔案 (McBo....zip is not commonly downloaded and may be dangerous)，不確定原因為何。我的下載路徑:

我的理解跟經驗：因為 2.2.1 版的發行檔還沒有被很多人下載過，Chrome 判定為不常見（而非危險的）檔案。這訊息通常會在安裝檔有足夠多人下載後，自動消失。

[lukhnos]

我們注意到 Homebrew 已經將小麥的安裝資訊更新到 2.2.1 了: Homebrew/homebrew-cask#119349

我們也更新了 FAQ: https://github.com/openvanilla/McBopomofo/wiki/常見問題#會建議透過-homebrew-安裝嗎

另外我有注意到先前提供的關於如何透過 CI flow 更新 brew formula 的方式。這一點請參考我們的 FAQ。

[xareelee]

謝謝回應。

不過我還是建議使用 GitHub Actions 配置 CI/CD 在打 tag 上新版本時，自動就可以觸發這些重複又瑣碎的事。這不是單純能否透過 homebrew 安裝的問題，因為目前是靠手動執行 PR。自動化本身是很有價值的。

1. 任何人都能夠過 homebrew 得知有新版本發布，並確保從 homebrew 都是最新版本 (雖然小麥本身也提供了自動更新機制)。
2. 支援 homebrew 意味著任何新電腦的配置，或是需要管理多台 mac 的安裝，都能透過腳本化自動執行。

這邊只是建議做個 GitHub Actions 的配置，過程並不難，而可以省下許多重複工作的時間，而且這項技能也能應用在其他 GitHub 項目上。

另外幾個問題想請教，

1. 關於小麥輸入的配置，能否像 RIME 一樣支援文件設定 (例如 .yaml)，並且統一放在集中路徑 (跟詞彙一樣放在 ~/Library/Application Support/McBopomofo)，這樣方便使用像 mackup 這類檔案同步工具，在搬移電腦時能夠自動化同步。
2. 能否提供更多客製化選項，修改輸入法引擎本身以及 UI 介面上的改良 (像 RIME/Squirrel 一樣)？

[lukhnos]

謝謝你的建議。

我們幾個人比較少機會討論開發原則，所以以下僅代表我個人的看法：

自動化本身是很有價值的。

同意。我們在 2.x 改版過程中大幅增加了 test coverage 也更善加利用 GitHub actions，也已經看到成效。

不過 Homebrew 的支援上：

1. 我本身希望減少 mission creep。如果有人願意維護小麥的 homebrew release workflow （不管是以小麥維護者身分或就是 homebrew contributor 身分），我想大家都會樂見其成。
2. GitHub repo release page 本身是有 atom feed 的，或許希望透過 subscription 模式知道有新版發布的 IT 用戶，可以透過這樣的方式來取得新版訊息？
3. 目前小麥的 homebrew install 過程並不直觀，畢竟打完 brew install mcbopomofo 後還是得手動執行安裝程式。如果是以 IT 管理角度來看，我不確定是否 brew 有解決腳本化管理的需求？

另外，

關於小麥輸入的配置，能否像 RIME 一樣支援文件設定 (例如 .yaml)

小麥的設定都放在 ~/Library/Preferences/org.openvanilla.inputmethod.McBopomofo.plist 中。Properly list 因為蘋果平台強勢了，應該已經不算是少見的格式。我個人是希望直接利用內建的設定格式。同樣也是減少 mission creep。

能否提供更多客製化選項，修改輸入法引擎本身以及 UI 介面上的改良

看看其他小麥開發者怎麼想。

從我這邊看，過去以來小麥提供了一些「隱藏選項」，讓使用者透過終端機自己調整參數。我想原則上，小麥的態度比較像是「我們設想了一些 good defaults」，而隱藏選項的意思代表「這並不是我們自己會用到，或是測試或維護上的 golden path；單一的選項我們也許能確保 API contract 的運作，合併在一起的 combinatorial explosion 就只能是 best effort」。這樣的模式似乎維持了一個還不錯的平衡。如果要有更多客製化選項，那代表那樣的平衡會改變。

[xareelee]

3. 目前小麥的 homebrew install 過程並不直觀，畢竟打完 brew install mcbopomofo 後還是得手動執行安裝程式。如果是以 IT 管理角度來看，我不確定是否 brew 有解決腳本化管理的需求？

或許可以考慮改用 .pkg 方式進行發布。鼠鬚管 (RIME/Squirrel) 是以此方式進行發布，且搭配 homebrew 可以直接安裝完成，並直接加入到 Input Sources 中，不需要再手動安裝或是到 System Prefereneces 中設定。

因為我已將 99% 配置 Mac 的工作腳本化，幾乎所有配置工作都以腳本化進行。因此若能完全自動安裝好輸入法、並完成文件配置同步，這樣是最好。畢竟手動配置新 Mac 工作環境總是件麻煩事。

[xareelee]

小麥的設定都放在 ~/Library/Preferences/org.openvanilla.inputmethod.McBopomofo.plist 中。Properly list 因為蘋果平台強勢了，應該已經不算是少見的格式。我個人是希望直接利用內建的設定格式。同樣也是減少 mission creep。

我不太確定 McBopomofo.plist 是否都是只放 user 的設定資料，還是 McBopomofo 本身有可能會去自動修改該 plist (例如版本更新而需要添加新的設定)。

若為是，則這本身存在一點小問題 (但目前不太大)。通常設定最好把 default settings 和 user settings 分開來，並且 user settings 可以覆蓋 default settings。

1. App 提供新功能，給予的參數都修改 default settings 即可，不會動到 user settings。
2. 用戶可以參考 default settings 的設定，並將要修改的設定寫入 user settings。
3. 用戶只需要維護和同步 user settings 即可。

這樣可以避免非使用者意願的修改 settings (也就是程式所為)，而需要提交變更到 git repository (變成要追蹤非 User 造成的變更)。

使用 .plist 時，用戶不知道程式是否會在什麼時候更新這些設定。而且裡面可能有非常多的設定其實是用戶不關心的 (例如有 1000 個 key-value pairs 設定)，用戶可能只想 review 在乎的幾個 (資訊量過大也是一種成本)。

而使用像 .yaml 之類的額外的配置檔，通常意味著程式不會主動修改該檔案設定。另外的好處，就是可以寫 inline comments，以後 review 可能會比較快知道當初放這些設置的原因。