My OSS Wish List

f:id:NyaRuRu:20150914052437p:plain

業務外にパッチを書いたりしている OSS プロジェクト，だいぶやりたいことが溜まっているので，優先順位をつける意味でもまとめてみた． 業務と基本無関係なので，代わりにやっていただくのは大歓迎．なので以下は Wish List ということにしておきたい．

OSS Mozc 関係

[Mozc] Windows 版向けのインストーラーをビルドできるようにする

2013 年に Windows 版のコードを概ねオープンソース化したときに，面倒で後回しにしたのがこの部分． プロダクト版の WiX スクリプトは実際公開済みではあるのだけど，自動アップデート関係の設定等もここで行っているため OSS 版のインストーラにそのまま転用できなくなっている． 技術的な障害は何もなく，OSS 版向きでない処理を取り除くだけ，なんだけどずるずるとはや 2 年半ぐらい．

やること．

  • OSS Mozc 向けに，余計なものを取り除いた WiX スクリプトを書く
  • ビルドに必要な WiX のインストール方法を決める．OSS Mozc のリポジトリにチェックインしてしまうか，choco install wixtoolset あたりを使う．

[Mozc] DirectWrite を使うと真っ白になる問題を再現させる

候補ウィンドウの DirectWrite で表示するというコードを実装したのがだいぶ前の 2013 年 12 月ごろ．先日こいつが安定版に取り込まれ，それなりの数のユーザーにリリースされたところ，文字が全く表示されなくなるという問題が各所で起こることが判明．急遽該当コードを無効化するという事態に． 報告を読む限り Windows 7 環境限定っぽいのですが手元で再現できていないので詳しいことはよくわからず．

やること．

  • 再現環境を入手する
  • Mozc の実装に問題があるかどうかを調査する．問題があれば修正する．
  • もし環境側の問題であれば，それを検出する方法があるか調査する．
  • DirectWrite を用いた表示を無効化する設定を設定ダイアログに追加するべきか検討する．必要があればその実装．

[Mozc] ソースコードのチェックアウトプロセスから Subversion 依存を取り除く

Mozc Issue #299 参照． 技術的な障害は何もなく，淡々と手を動かせば終わるはず．

[Mozc] 依存する外部リポジトリの管理を gclient から Git submodule に変更

Subversion 依存が取り除かれれば，あとは機械的に対応可能．

[Mozc] ibus-mozc の削除

Mozc Issue #287 及び Mozc Issue #194 参照． これは割と自分の都合でお願いして削除することを決めてもらった話なので，早いところ何とかしたい．

ibus-mozc に関しては主に 2 つの理由からサポートをやめたいと思っていた．ひとつはメンテナー不在という問題，もうひとつは互換性問題の多発による周辺プロジェクトの疲弊がある．

メンテナー不在に関しては単純で，自分の空き時間の使い道としては優先順位が高くない，というのが理由である． 自分が OSS Mozc のメンテナンスを引き受け始めたころには，既に Chromium OS は IBus の使用をやめており，ibus-mozc を業務でメンテナンスする人間はいなかった． 自分の場合 OSS 関係のプロジェクトに関しては基本的に業務外時間で面倒を見ていて，そのため土日にできる範囲で作業するというスタンスを取っている． 日本語入力については，Windows と Android であれば日常的に使っているという意味もあってまだ興味が持てるものの，Linux Desktop 上で日本語入力することは基本的にない． そのため，既知のバグを概ね直しきったところで手を引くべきだと考えていた． Mozc Issue #194 という Issue を立てメンテナーを社内外から募集してみたのが 2 年ほど前． 残念ながら特に引き取り手は現れなかったので，まだ作業する余裕があるうちにコードを削除してしまおうというのが現在の考えである． というものの実際ここ数ヶ月は時間がとれずに作業が進んでいなかったので，もう少し早く始めていれば良かったのかもしれない．

互換性問題に関しては，複雑だ． IBus 1.4 あたりから，IBus の様々な処理が非同期プロセス間呼び出しとして実装されているのだけど，自分が普段使っているアプリケーションを中心にこれが何度も互換性問題を引き起こしている．

自分の理解が正しければ，もともと Chromium OS でのパフォーマンスを稼ぐために寄せられたパッチ群がもとで ibus が非同期処理を多用し始めた，という歴史だったように思う．とすれば不幸としか言いようがない． とはいえ同僚が今もこの件で時間を消費していることを考えると，多くのユーザーには IBus 以外の実装に移って欲しいという気持ちもある．心境としては複雑ではあるのだけど．

やること．

  • 社内リポジトリで変更済みの ibus-mozc 関係の更新を全て OSS 化
  • ibus-mozc 関係のコードを全削除
  • fcitx-mozc 等の代替ソフトウェアに足りない機能があれば，可能な範囲でそちらへの協力．
  • IBus の非同期モードが問題を引き起こしている周辺プロジェクトへのできる限りの協力．

[Mozc] tsf-mozc の Windows 10 関係の互換性問題の調査

やること．

  • Windows 10 環境を作る
  • 色々と言われている問題が再現するか調査．再現するなら直す．

[Mozc] Windows 環境での縦書きサポート

ずっと言われているのでどこかで時間を取って何とかしたい．候補ウィンドウ側に関してはハッカソンで一回動くところまで作ったことがあって，2 日もあればそこまではできることは確認済み． 問題は変換エンジン側で，縦書き時にカーソルキーの意味が変わるという動作をきちんとプロトコルレベルで定義する必要がある．

やること．

  • 候補ウィンドウの縦書きを実装．テストも追加．
  • 縦書きと横書きでキーマップを入れ替えるためのプロトコルを定義する

[Mozc] Qt 5.x への移行

Mozc では依然として Qt 4.8.x 系を使っているのだけど，いくつかの理由から 5.x へのアップグレードを急ぐ必要がある．

  • Qt 4.8.x では Windows の HiDPI 環境をサポートできない．これはだいぶ深刻．
  • 様々な Linux ディストリビューションが Qt 4.x のサポートを打ち切りたがっている．

基本的には Qt のアップグレードでビルドが通らなくなるところをひたすら直していく以外にないのだけど，Qt にパッチを当てずに移行可能かはまだ未知数． また，ビルドが通っても特定ユーザー環境で問題が発生する可能性もあり，先は長い．

[Mozc] Linux および Android 向け Continuous Build / Test 環境の整備．

現在の OSS Mozc は，Windows と OS X に関してある程度の Continuous Build / Test 環境が有効化されているものの，Travis CI が長らく Linux 12.04 にとどまっているため Linux および Android に関しては有効化できていなかった． 最近 Travis CI が Docker をサポートを追加したらしく，そろそろ何とかなりそうな気がしている．

[Mozc] その他溜まっている OSS Mozc の更新

Mozc の開発は現在も社内リポジトリが master． OSS リポジトリの更新タイミングは，基本的に誰かの手が空いているときであって，ここ 1 年半ぐらいは自分が土日及び休暇の空き時間を利用して行っている． で，ここのところ時間がとりにくかったのもあって，OSS 化すべき更新が 7 ヶ月分ぐらい溜まっている．

やること．

  • 作業のさらなる自動化．
  • ビルド確認の手間を減らすべく CI の拡充．

gclient から git submodule に移行すれば，GitHub 界隈のエコシステムをもうちょっとうまいこと活用できるんではないかと期待．

GYP 関係

[GYP] Revert された 540e4b1e665 の再有効化

これは完全に巻き込まれ案件なのだけど，個人的に気になっていて何とかしたい．以下時系列．

  1. いくつかのビルドツールで問題を起こすことから，GYP は同一ビルドターゲット内に (ディレクトリだけ異なる) 同名ファイルが存在することを許さない．一方，社内外からこの制限が不便だという声があがっていた．
  2. 数年前，社内リポジトリにとりこまれたバージョンの GYP に，このファイル名チェックを回避するオプションを追加するローカルパッチが提案され，メンテナンスを担当していた自分はうかつにもこれを受け入れてしまう．以後，アップデートのたびにパッチを当てなおす必要がうまれメンテナンスコストが増大．
  3. 自分が中心となって，GYP upstream に同等のオプションを実装 GYP r1947．
  4. 上記機能が実装された GYP を社内にインポート．いくつかのプロジェクトがそのオプションを有効にする．
  5. とある Chromium 開発者，この制限を完全に取り除くパッチを提案．受け入れられる．GYP r1993．
  6. 上記機能が実装された GYP を社内にインポート．不要になったオプションは削除される．
  7. GYP r1993 が，Chromium のビルドで警告を引き起こすことが分かり revert される．GYP c0cf1f22eb

というわけで，最新の GYP をそのまま社内にインポートすると，いくつかのプロジェクトでビルドが壊れることが分かっている．何とかしたい． この問題，自分の理解では OS X の libtools の制限によるもので，XCode では技巧的な方法で回避済み．同じことを GYP の Ninja ジェネレータでも実装すれば済む話，なんだけど時間が取れずまだ何もできていない．

が，こうやって書いてみると，自分的には最新の GYP がインポートできれば十分なので，もう一回社内の該当プロジェクトにオプション追加すれば良いだけのような気もしてきた……

やること．

  • 自分で直すまたは代わりにやってくれる人をみつける．

Chromium 関係

[Chromium] Web MIDI の実装に Windows 10 の新 MIDI API が使えるか調査

Chromium Issue #512433 参照． Windows 10 には MIDI API が追加されていて，Windows 版 Chromium の Web MIDI がもっと使いやすくなる可能性がある．

やること．

  • 自分でやるまたは代わりにやってくれる人をみつける．
  • 自分でやる場合，まずは Windows 10 環境を作る．

[Chromium] その他 Chromium の Web MIDI サポートで担当者募集中バグの修正

2015 年 9 月 13 日現在 24 個の担当者募集中バグがある． しかしこれはちょっと分量的につらいかも．

やること．

  • 自分でやるまたは代わりにやってくれる人をみつける．
  • MIDI の meetup 等で協力者を募る．

[Chromium] Android Lollipop で追加された新 IME API のサポート

Chromium Issue #424866 参照． 去年 Android Lollipop に追加した CursorAnchorInfo API，Chromium でまだサポートされていないのでなんとかしたい． 実はパッチまでは既にあるのだけど，Chromium 特有のレビューコスト・パフォーマンスに関する敷居の高さに阻まれ中断中． これはひょっとしたら業務時間中にやりきる口実を見つけられる可能性もゼロではないのだけど，その時間を Android 本体に使ったほうがどう考えても合理的なので早いところ担当してくれる Chromium 関係者を見つけるべきだと思っている．

やること．

  • 代わりにやってくれる人をみつける．あるいは気合を入れて自分でやりきる．

Firefox 関係

[Firefox] Android Lollipop で追加された新 IME API のサポート

Mozilla Issue #1094729 参照． 去年 Android Lollipop に追加した CursorAnchorInfo API，Firefox でまだサポートされていないのでサポートされて欲しい． 新 IME API が自社製品でしか使われないというシナリオは避けたい．心の底から．それが Microsoft ウォッチャーとして Text Services Framework から得た教訓なのですな．

やること．