Fcitx-mozc を試してみた

(4/7 追記) fcitx-mozc の master branch では下記の問題は修正されたようです．Great!

Fcitxのテストのお願い - いくやの斬鉄日記 というのがあったので，軽く動作を見てみました．環境はこんな感じ．

  • Ubuntu 13.04 Final Beta 64-bit
  • VMWare 9.0.2
  • Mozc / fcitx は 2013年4月6日午後8時(日本時間)の時点で，ppa:ikuya-fruitsbasket/fcitx に登録されていたバージョン

f:id:NyaRuRu:20130406212509p:plain
以下，ibus-mozc から後退する部分で気付いたものを列挙してみます．

一部の Ctrl 付きのショートカットが動作しない

  1. Open gedit
  2. Enable Mozc
  3. type "kyouha"
  4. hit Ctrl+H

Expected: "きょう"
Actual: "きょうは"

Mozc (というか Windows の代表的な IME は)，F7 キー，F8 キー，F9 キーの代わりにそれぞれ Ctrl+i，Ctrl+o，Ctrl+p という感じのショートカットが用意されています (QWERTY 配列では横に並んでいることに注目)．また，IME での入力中は Ctrl+h によってバックスペース相当の動作をすることも可能です．これらが fcitx-mozc では使えないようです．ibus-mozc 1.6.1187.102 では動作するはずです．
Mozc プロトコルでのモディファイアキーの扱いについては commands.proto で解説されて います．Windows 版 Mozc の keyevent_handler_test.cc にも大量にテストケースがあります．

ひらがな/カタカナキーが常にカタカナキーとして振る舞う

(On 109 Japanese keyboard)

  1. Open gedit
  2. Enable Mozc
  3. Type "a"
  4. Hit Shift+Hiragana/Katakana
  5. Type "i"
  6. Hit Hiragana/Katakana
  7. Type "u"

Expected: "あイう"
Actual: "あイウ"

期待される実装方法については ibus-mozc の以下のコードあたりが参考になるかと．
https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/key_translator.cc?r=131#57

  {IBUS_Hiragana, mozc::commands::KeyEvent::KANA},
  {IBUS_Hiragana_Katakana, mozc::commands::KeyEvent::KANA},
  {IBUS_Katakana, mozc::commands::KeyEvent::KATAKANA},

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/key_translator.cc?r=124#377

  // Due to historical reasons, many linux ditributions set Hiragana_Katakana
  // key as Hiragana key (which is Katkana key with shift modifier). So, we
  // translate Hiragana_Katanaka key as Hiragana key by mapping table, and
  // Shift + Hiragana_Katakana key as Katakana key by functionally.
  // TODO(nona): Fix process modifier to handle right shift
  if (IsHiraganaKatakanaKeyWithShift(keyval, keycode, modifiers)) {
    modifiers &= ~IBUS_SHIFT_MASK;
    keyval = IBUS_Katakana;
  }

一時的な英数モードからシフトキーで復帰しない

  1. Unset "L_SHIFT" from "Extra key for trigger input method" in the Fcitx global config.
  2. Open gedit
  3. Enable Mozc
  4. Hit key as follows
    1. Down Shift key
    2. Hit a key
    3. Up Shift key
    4. Hit i key
    5. Hit u key
    6. Down Shift key
    7. Up Shift key
    8. Hit a key
    9. Hit i key
    10. Hit u key

Expected: "Aiuあいう"
Actual: "Aiuaiu"

MS-IME のローマ字モードには，Shift キーと共に入力を行うことで一時的に英数モードに入るという機能があるのですが、この入力状態はシフトキーを単独で押すことで解除できます。fcitx-mozc ではこの機能が働かないようです。ibus-mozc 1.6.1187.102 では動作するはずです．

ツールを起動する系のショートカットが動作しない

  1. Open the config tool of Mozc
  2. Enter key customize mode
  3. Add an entry as "Precomposition/F2/Launch word register dialog"
  4. Open gedit
  5. Enable Mozc
  6. Hit F2

Expected: word register dialog is launched
Actual: nothing happens

Mozc (というか Windows の代表的な IME )はショートカットキーで設定ダイアログを起動したり単語登録ダイアログを起動したりできるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

gedit で確定取り消しが動作しない

  1. Open gedit
  2. Enable Mozc
  3. Type "kyouha"
  4. Hit enter to commit
  5. Hit Ctrl+BackSpace

Expected: commit action is canceled
Actual: nothing happens

Mozc (というか Windows の代表的な IME )は直前の確定動作を取り消せるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

gedit で再変換が動作しない

(On 109 Japanese keyboard)

  1. Open gedit
  2. Type something
  3. Enable Mozc
  4. Select some text
  5. Hit Henkan key

Expected: The selected text is reconverted by Mozc
Actual: nothing happens

Mozc (というか Windows の代表的な IME は)選択した単語を再変換できるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

冒頭にも追記したとおり，ここに挙げた問題は全て master branch では修正済みのようです．良かった良かった．

2012年他にやったこと - Mozc 編

Mozc 1.10.1389.102 が公開されたということやっと書ける感じの 2012年やったこと - Mozc 編 - NyaRuRuが地球にいたころ の続き．2012 年にやっていたことの今回公開分．

Support IBus 1.5

Red Hat によって主導され，GNU/Linux 界隈で使われている Input Method Framework であるところの IBus が，メジャーアップデートにあたって設定ファイルの解釈を変えるという決定を下したところ，挙動の変化に気づいたユーザーが IME 側にバグを登録してくることになり，IME 側で設定ファイルを変更することで対処することになったという案件．
平常心平常心と自分に言い聞かせつつ淡々と対処．

Increase opaque buffer size for x32

Mozc が日本語入力を提供しているところの Chromium OS から，x32 でビルドすると static assert に引っかかったからバッファサイズ変更してねとやってきたバグ．こんな身近に x32 を検討中のプロジェクトがあったのかという驚きの気持ちで淡々と対処……したんだけど，その後色々あって Chromium OS の日本語入力は PNaCl でビルドした Mozc が使われることになったため，たぶんこの修正は無意味なはず……

プロセス間通信の AppContainer 対応

Windows 8 で導入された AppContainer サンドボックス下で動作するストアアプリから Mozc を使うにはどうすればよいか考えて実装する，というお仕事．
Mozc のように out-of-process 型の IME にとって，サンドボックスは天敵．実際 Windows 8 のベータテストの段階から色々実験を行っていて，AppContainer から外部プロセスへは単純に名前付きパイプで通信できないというのは分かっていた……んだけど同時にどうしようもなく過ぎていく日々．もちろん胃は痛い．マルチプロセス設計を見直すというのは，Mozc のコード規模では既に悪夢と言ってよく，ストアアプリ対応を諦めるという選択までもがかなりの現実味を持つという状況．ほんと胃が痛かった日々．
結局 AppContainer 導入による Windows 開発への影響 - NyaRuRuが地球にいたころ で紹介したように，名前付きパイプの DACL にエントリを追加すればよいという情報を発見しほっと胸をなで下ろしたのが 8 月頃．
ちなみにこの手法，API の説明を読むに，out-of-process で動作するアクセシビリティ系常駐ソフトへの配慮から残された裏口のようにも読める．変化と互換性の間で綱渡りをする Microsoft らしい配慮がなければ，今でも没入型 UI で Mozc は動作しないままだったかもしれない．
今回公開されたコードでは，以下のうち "(A;;GA;;;AC)" を足している部分がそれ．
https://code.google.com/p/mozc/source/browse/trunk/src/base/win_sandbox.cc?r=131#247

case WinSandbox::kSharablePipe:
  // Sharable Named Pipe:
  // - Deny Remote Acccess
  // - Allow general access to LocalSystem
  // - Allow general access to Built-in Administorators
  // - Allow general access to the current user
  // - Allow general access to ALL APPLICATION PACKAGES
  // - Allow read/write access to low integrity
  ssdl += L"D:(D;;GA;;;NU)(A;;GA;;;SY)(A;;GA;;;BA)";
  if (SystemUtil::IsWindows8OrLater()) {
    ssdl += L"(A;;GA;;;AC)";
  }
  ssdl += allow_user;
  if (SystemUtil::IsVistaOrLater()) {
    ssdl += allow_rw_low_integrity;
  }
  break;

Mozc を Windows 8 対応させるにあたって，最も重要だったのはこの一行だといっても過言ではない．

TSF 再対応

Windows 8 の没入型 UI では TSF ベースの IME (正確には Text Input Processor; TIP) 以外は使えないというのは割と知られた話．しかし実際の ところ迫害はこれにとどまらず，デスクトップモードでも IMM32 ベースの IME には次のような制限がある．

  • 言語バー API を使用して，通知領域にアイコンを表示できない
  • 言語設定から IME の設定画面を開けない

正直 Windows 8 では IMM32 ベースの IME は現実的とは言えないんじゃなかろうか．
このような理由もあって，Mozc を TSF に再対応させるのは割と早いうちから決心していた．もっとも，プロセス間通信の問題の方がより頭が痛かったので TSF の問題は割と放置気味だった．
プロセス間通信の問題が片付いて，Chromium の TSF 対応も一段落しところで，一人で淡々と TSF 対応を開始．それも無事 12 月中にすべてリリース．短期間に大量のコードレビューをこなしてくれた同僚に感謝．
こうして，IMM32/TSF との関わりがまた増えた．

  1. 学生時代に C# で TSF ベースの IME を途中まで作る
  2. 学生時代に Windows Vista 向け TSF 対応記事を書いたり CEDEC で講演したり
  3. 入社後，TSF で書かれていた初代 Mozc クライアントの開発を手伝う
  4. Windows XP 環境での CUAS に絶望し，IMM32 で Mozc クライアントをゼロから書き直す
  5. Chromium の TSF 対応を指揮
  6. Windows 8 向けに Mozc クライアントを TSF で書き直す (New!)

今回書き散らかしたコードはこのあたりに見ることができる．
https://code.google.com/p/mozc/source/browse/trunk/src/#src%2Fwin32%2Ftip

vcbuild から Ninja への移行

2012 年末，TSF 対応コードを一通りリリースし終わった後，同僚たちが休暇モードに入るのを横目に始めた年末ビルドパイプライン大掃除．
Mozc の Windows ビルドは，gyp のおかげで柔軟性が高く，ターゲットとなる Visual C++ のバージョンを変更するのは容易である．実際手元の開発では Visual C++ 2012 + Visual Assist X で快適開発ということが割と簡単にできている．一方，ビルドサーバーはいまだに Visual C++ 2008 を使っていた．これに関して最近以下のような懸念点があった．

  • Chromium がデフォルトコンパイラを Visual C++ 2008 から Visual C++ 2010 に移行した
  • Visual C++ 2010 になると，nullptr や auto が使えるようになる

そんなわけで，Mozc のデフォルトコンパイラを Visual C++ 2008 から Visual C++ 2010 に変更しようと思い立つ．
この変更で問題になるのは，従来コマンドラインからのビルドに使っていた vcbuild.exe が使えなくなり，.NET ベースの msbuild.exe に移行しなければならないことである．密閉型のビルドサーバーに .NET ベースの複雑な依存関係を持ち込むのはうれしくない．そこで，最近 Chromium でも併用されている ninja を使ってみることにした．
Ninja は，当時 Chromium チーム に在籍していた Evan Martin による make 代替ツールで，gyp や CMake のようなツールから自動生成されたビルド設定を読み込むことを前提に，とにかく高速に動作することを目指している．Ninja は Chromium 開発で多用されているだけでなく，最近は LLVM のような CMake 利用プロジェクトにもファンを広げているようだ．今回 vcbuild.exe ではなく Ninja を採用したもう一つの理由は，社内で勢いを持ちつつあるツールにはなるべく乗っかっておくという経験則もある．困ったときに聞きやすいし，自分の経験が同僚の役に立つこともある．
もっとも，Chromium 付随プロジェクトにありがちな話として，Chromium が必要になった部分だけ実装され，他は未実装というのは今回も同じ．Mozc を gyp + Ninja + Visual C++ 2010 で快適にビルドするには，gyp の Ninja 向けジェネレータ側にいくつか追加実装を行う必要があった．12 月頃せっせとパッチをアップストリームしている姿を以下に見ることができる．

移行は無事予定していた期間で終わり，現在の Mozc のビルドサーバーは gyp + Ninja + Visual C++ 2010 で動いている．

その名は「新しい (Windows) UI の…」

Windows 8

発端

マイクロソフト社がIEの舵取りに迷っている。同社は先週、Windows 8の“Windows ストアアプリ”として動作する「Internet Explorer 10」でFlashコンテンツを表示する際の方針を変更すると発表した。この方針転換が意味することを理解するためには、Windows 8が発売される前までさかのぼる必要がある。

【＃モリトーク】第50話：IEのジレンマ - 窓の杜

という記事を読んだのだけど，どうも用語の使い方が危なっかしい．枝葉の部分ならともかく記事の論点に直結する部分だけに余計に気になる．というわけでちょっとだけ書いてみたのが以下．

Windows 8 向けブラウザの 3 分類

Windows 8 でウェブブラウザというと，大きく 3 種類に分けられる．

  1. いわゆる Windows ストアアプリであって，標準ブラウザコンポーネントを利用するもの
  2. いわゆるデスクトップアプリケーションとして動作するブラウザ
  3. Windows ストアアプリではないものの，Windows ストアアプリと同様の没入型 UI で動作するブラウザ

単独製品としての「Internet Explorer 10」が該当するのは 2 と 3 である．この厳密な定義に従えば，元記事にあった，

“Windows ストアアプリ”として動作する「Internet Explorer 10」

なるものは，実は存在しない．元記事に登場する Google Chrome も同様で，“Windows ストアアプリ”として動作する Google Chrome というものは存在しない．Chrome もタイプ 2 とタイプ 3 で動作する．
なぜこの区別が重要かというと，タイプ 3 のブラウザは，没入型 UI で動作するという点ではタイプ 1 に近いものの，開発者視点ではむしろタイプ 2 のデスクトップアプリケーションとしてのブラウザに近いからだ．タイプ 1 ブラウザと対照的な，タイプ 3 のブラウザの特徴を挙げてみよう．

  • AppContainer サンドボックスが強制されず，Integrity Level Medium で起動される
  • WinRT に縛られず，デスクトップアプリケーションとほぼ同等の Win32 API にアクセスできる
  • Windows ストアを経由せずにインストールできる

このように，タイプ 3 ブラウザは，実際にはデスクトップブラウザと同じ技術で作られている．プラグイン的な実行時ライブラリの使用や，JIT コンパイルのような実行時コード生成についても特に技術的な制約はない．
もう一点強調しておくと，Windows 8 で没入型 UI が導入されるにあたって，こんな動作モードが許されたのはブラウザだけである．この動作モードが許されるのはデフォルトブラウザに限定され，その他のブラウザには許されないというところからも，今回の措置が例外的なものであることが透けて見える．

参考資料

Windows 8 のサードパーティー製ブラウザ事情については，Microsoft がブラウザ開発者向けに公開している Developing a new experience enabled desktop browser という資料に詳しい．なかでは，Windows 8 で動作するタイプ 3 のブラウザを開発する方法について解説されている．プロセス分離型ブラウザについても言及されているあたり個人的には好感度が高い．
ちなみにこの資料で，タイプ 1, 2, 3 ブラウザはそれぞれ以下のように呼ばれている．

  1. Windows Store app
  2. Desktop browsers.
  3. New experience enabled desktop browser

3 については，"New experience enabled" のあたりに没入型 UI を，"desktop browser" のあたりに API 的な側面を感じるとよいのではなかろうか．

きみの名は……

さて，以上の話を理解してから見る次のツイートは味わい深い．



背景事情が分かってしまえば簡単な話である．つまり，開発者向け資料で New experience enabled desktop browser と呼ばれる動作モードの IE が，ユーザー向けには "新しい (Windows) UI の IE"、"Windows 8 スタイルの IE" と紹介されているわけだ．まあ他に呼びようなかったのやもしれず．

Dell の個人向け商品で領収書をもらう方法 (または，まともなタッチ対応ディスプレイを経費で買う方法)

Windows 8 Windows 7

まとめ

Dell の 10 点タッチ外付け 23 インチディスプレイ S2340T は，個人向けサイトにしか載っていないけど，経費購入に必要な領収書も用意してもらえるので必要な人は迷わず買うと良いよ．

S2340T

Windows 8 に起因するタッチ対応案件は第一弾が一段落したころでしょうか．「Windows 7 のときに済ませた」という人から，「まだ対応していない」，「テストすらしていない」，「積み残しタスクがある」，という方まで，色々いらっしゃることかと思います．
そんななか，まだタッチ対応アプリケーションの開発体制を整えていなくて機材を探しているという場合におすすめなのが Dell の 23 インチディスプレイ S2340T．この製品，Full HD (1,920 x 1,080)，10 点タッチに対応しつつ，59,980 円という Windows 8 前のタッチ対応外付けディスクプレイからは考えられない低価格で．半年前に発表されるやいなや注文が積み上がり，一時期は通常納期 + 14 週間というすさまじいバックオーダーが生じていました．それが最近は需給が釣り合ってきたらしく，ついに通常納期まで改善したようなのでおすすめしてみる次第であります．

(参考) 製品紹介記事:
screenshot screenshot screenshot
さて，この製品を経費で買おう思ったあなたに一点アドバイス．S2340T は Dell の個人向けサイト にのみ掲載されており，法人向けサイトには掲載されていません．これで困るのが領収書．通常の注文フローだと会社名・事業者名宛ての領収書が作れないっぽく見えるため，経費で買おう企んでいた人はそこで諦めてしまいかねません．私の場合，諦めきれなかったので Dell のサポートの人に聞いてみたのですが，実は個人向け製品でも領収書は作れるとのこと．

Q 領収書を発行可能ですか？
A 領収書は、現金払いでのご注文の場合原則”お振込票の控え”等をもって代えさせて頂いております。現金以外のお支払方法ご利用の場合、お客様よりご希望のあった場合のみ発行しております。ご希望の場合はこちらのフォームよりご連絡いただけますようお願い申し上げます。
※個人のお客様で現金前払いのお客様には弊社にて入金確認後「入金確認書兼領収書」を郵送させていただいておりますのでそちらを領収書としてご利用いただけます。
※領収日は現金前振込の場合はご入金の確認がとれた日・クレジットカードの場合はカード会社より引き落としを承認された日になります。(領収日の変更は承ることが出来ません。)
※領収書のお届けは納品後となり、お時間がかかることもございます。また商品には同梱できませんので、予めご了承ください。

よくあるご質問

流れとしては，以下のようになるようです．
1. 個人向けページから購入する．
2. 領収書発行フォーム から領収書を請求する．

というわけで，S2340T の納期も改善してきたタイミングでの，タッチ対応 Windows アプリケーション / Web アプリ開発者向け情報でしたー

看板の話

【注意】I'm not a lawyer だよ! This is not legal advice だもんね!

Piro さんが長文を書かれていたので一部だけ切り出してつまみ食い．ただし GPL vs BSDL の話ではなくて看板の話．

  • 自分の作った物が誰にどう使われようとも構わない、極端な話、誰かが看板だけ掛け替えた「改良版」を作って商売していようとも全く構わない、という事であれば、パブリックドメインにしたり、あるいはBSDスタイルのライセンスを選択して問題ないでしょう。
  • 自分の作った物が看板を掛け替えただけの「改良版」として勝手に商売に使われるのは我慢ならない、やるならこっちにも分け前をよこせ、それが嫌なら無償で同じ条件でソースも含めて公開しろ、という事であれば、コピーレフトなライセンスを選択した方がいいでしょう。
  • 自分の作った物がアイデアだけ引き継がれるのはいいけど、自分の血と汗と涙の結晶であるソースコードが他人にそのまま利用されるのは腹立たしい。アイデアを同じように具現化したかったら、自分で同じだけの血と汗と涙を投じて実装し直して欲しい。という事であれば、ソースコードを公開しないクローズドライセンスにした方がいいでしょう。
  • 自分の作った物がソースコードも含めて引き継がれていって欲しい、他の人が自分と同じような苦労をしなくてもいいようにしたい、人類共有の財産にしたい、という時に、コピーレフトにするべきなのか、それともBSDスタイルにするべきなのか。そこが問題です。
Latest topics > 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - outsider reflex

これを読んで看板の方に反応しちゃったというか，つまり，ソフトウェアに十分以上の思い入れがあるなら，商標とるのも選択肢に入れるべきですかねと．

  • 自分の作ったソフトウェアに対するブランドイメージが，第三者の「改良版」で勝手に使われたり左右されたりするのは我慢ならない．ブランドに影響する活動はぜんぶうちを通してもらうし，新たに何か立ち上げるならブランド構築はゼロからスタートしてもらう → 商標取ろう
  • 自分の作ったソフトウェアに対するブランドイメージが，第三者の活動によってどう利用され・変化しようとかまわない．勝手にやってくれ． → なにもしない or 商標のとれない名前 (地名とか?) を使おう？

て感じなんですかね．
前者の例は，プロプライエタリなソフトウェアはもちろん，OSS の世界でも大手 Linux ディストリビューター (Debian, Fedora, Ubuntu, ...) や Mozilla，Arduino にしろ企業っぽいところはたいていそうです．仮に「改良版」で何か活動しようとしたい場合でも，看板の付け替えはほぼ確実に要求されています．仮に OSS のライセンスを守って著作権をクリアしても，あなたは Debian Lite とか Fedora Lite とか Firefox Lite という名前を使えないことになります．たぶんね．
後者としては，「～ごった煮版」「私家製～」「偽～」「Patched ～」「～版○○」とか煮え切らない名前で公開されているたくさんのソフトウェアの周辺にいくつもの例を見つけることができるでしょう．fork の盛んな OSS の世界ではこういった例もたくさん見ることができます．
つまるところ，あなたが活動を行う上で，ブランドに対する姿勢によっては，商標が必要になるケースがあります．これはOSS・プロプライエタリどちらでも行われていることで，いずれの場合であっても世に先例を見つけることができるでしょう．

2012年やったこと - Chromium 編

前回に引き続き今度は Chromium 編．chromium.org のアカウントを作ってもらったはいいものの，メールアドレスの 1 文字目を大文字にされて激しく凹むということもあった一年．

Windows 8 向け TSF 対応

Chromium を Windows 8 向けに TSF 対応させるというミッション．いやな予感はしていたものの，Mozc の TSF 対応もあるのであまり積極的に手を出せずにいたら，結局ぎりぎりになって火消し案件として振ってきた，という感じの一件．

Windows 8 では IME の TSF 対応が注目されていたりするわけだけど，実は Immersive Mode で動作するブラウザの方も TSF に対応させる必要がある．対応させないと Immersive Mode で CJK の入力ができない．それはまずいというわけで TSF を扱ったことのある Mozc チーム (もっとも Mozc で TSF 経験者といっても私ぐらいだけど) に話が回ってきた．のが 7 月終わりから 8 月頭にかけて．Windows 8 の MSDN 向けリリースは 8 月 15 日．一般リリースは 10 月 26 日．
「どうしてこんなになるまで放っておいたんですかー！」……といっても始まらないので一時期は Mozc チームから 5 人ぐらいヘルプに回しつつ，6 週間 (これは Chromium の平均的なリリースサイクルでもある) でどうにか動くものをでっち上げる．結局細かいバグまで全部取り除くにはもう 1 サイクル (6週間) かかったけど．
この間 Mozilla 方面からはこういう声も聞こえてきたり．


まあ実際は 5 人全員が働きっぱなしということはなくって，内容が専門的になってくるにつれ段階的に人数を減らしていく感じで．戦力の逐次投入の逆ができたという点では満足．
ちなみに自分はリードエンジニアとして参加しつつ，コードを書くよりは主に設計と裏方に注力 (TSF 未経験者ばっかりなので，こうする方がむしろスケールすると判断)．全コードのレビューをしたり，ドキュメントをメンテしたり，TSF についての軽い Tech Talk をしたり，Windows のデバッグテクニックのレクチャーをしたり．あとはアーキテクチャ上の最終決定を行ったり (これは胃が痛かった…)．同僚がもりもりコードを書いてくれたのでほんと助かった．ぺこり．
もちろん反省点も色々ある．一番大きな反省点は，Chromium のコードレビューに不慣れな人間 (自分含む) がいることを考慮していなかったところ．アプリケーションの TSF 対応では，メッセージポンプやテキストウィジットに手を入れる必要がある．もちろんこれらは重要コンポーネント，大物レビュアーが出てくるし自然とレビューの目も厳しくなる．もうちょっとコミットログや事前の根回しに注意していれば，レビュー期間は半分以下に収まったんじゃないかと思う．最初のキックオフの時にレビュー対策を盛り込んでおけば…… このあたりの文化的背景については @omo2009 先生がすばらしい記事を書いていらっしゃるので興味がある人はこちらをどうぞ．

Handle IMR_QUERYCHARPOSITION even when there is no composition

コンポジション文字列が存在しない時でも IMR_QUERYCHARPOSITION に応答するという変更．実際には単にカーソル位置を返すだけ．

Mozc の TSF 対応を行なっている時に気づいた問題で，空文字列に対するITfContextView::GetTextExt でカーソル位置を取得するためにはこうなっていたほうが都合が良い，という変更．
ブラウザと IME 両方に手を出していると，楽な側で直せるというのは便利．具体的には以下の差が現れる．
f:id:NyaRuRu:20130103213724p:plain
f:id:NyaRuRu:20130103213730p:plain
Chromium 24 にてリリース予定．

2012年やったこと - Mozc 編

いままで仕事で書いたコード (Chromium とか Mozc とか) については基本的に言及しないようにしていたんですが，ソースコードが公開されている内容についてはまあいいかということでまとめてみます (もちろんソースコードが公開されていないことについても色々やってますが)．とりあえず Mozc 編*1．順序は概ね時系列．

Visual C++ 2010 対応

ちまちまとコンパイルエラーに対処．ビルドスクリプトを vcbuild に加えて msbuild にも対応させたぐらい．あとは gyp にも問題を見つけたので一件パッチを upstream．

1.3.975.10x にてリリース．

SHOW_INFOLIST_IMMEDIATELY compatibility flag

Windows 環境でのバグ．
Meadow 3.0 や NTEmacs 22 で Mozc を利用していると，用例ウィンドウが表示されないというバグ．Mozc 開発チーム内で発見されて回ってきたもの．
これの原因がなんというか脱力系．もともと用例ウィンドウは「最後の UI 更新から 500 ミリ秒経って何のアクションも起きていなければ表示する」というロジックで動いていた．ところが，Meadow 3.0 や NTEmacs 22 はポーリングを行っていて，より短い間隔で IME の UI 更新通知を送ってくる (実際には更新する必要がないケースでも)．これをトリガーとして候補ウィンドウの再レイアウトが行われるため，永遠に「最後の UI 更新から 500 ミリ秒経過」という条件が成立しない．
これらのアプリケーションではディレイなしに用例ウィンドウを表示するようにして対処．

1.3.975.102 にてリリース．

「半角空白を入力」が動作しないバグの修正

たまには変換エンジン側のバグも直してみようキャンペーン第一弾．
カスタムキーマップにて「半角空白を入力」「全角空白を入力」というコマンドが選択可能であるにも関わらず，特定条件でうまく動作しないという問題，の修正．

1.4.1003.10x にてリリース．

キャンセル後 IME を無効化

たまには変換エンジン側のバグも直してみようキャンペーン第二弾．
ATOK と MS-IME のデフォルト設定の違いのひとつに，IME をオフにしたときに未確定の入力文字列を確定させるかそれともキャンセルさせるか，というものがある (MS-IME では確定，ATOK の ATOK キーマップではキャンセルさせるのがデフォルト)．
これまでのバージョンの Mozc では MS-IME にあわせて確定させていたのだけど，やっぱり ATOK スタイルが良いという人もいる．そういう人のためにカスタマイズの幅を増やしてみたという変更．
といっても，これ以上コンフィグオプションを増やしたくはないよねということで，「キャンセル後 IME を無効化」というキーコマンド側を追加することで対処してみた．この方法だと，ATOK キー設定に自然に対応させられるのもよし．

ATOK (キーマップ) 派の人向けに実装しただけのつもりが，なぜか vim 方面の人に受けるという不思議な経験もした．

バージョン 1.4.1003.10x にてリリース．

サロゲートペア対応

クライアント側と変換エンジン側両方の修正．
Windows クライアントに関しては，実際サロゲートペア対応をサボっていたのでその対応を粛々と．再変換とか確定取り消し周りが地味にめんどくさかった．
変換エンジン側は，UTF-8 を UCS2 に変換して処理している箇所がいくつか残っていたのでその残党狩り．
この変更のおかげで，後の Unicode 絵文字対応がそこそこ楽になる．
バージョン 1.4.1003.10x にてリリース．

Mozc Issue 14

uim-mozc の開発者の人からのレポートで，Protocol Buffers のライブラリと動的リンクしていると，起動時にエラーになるので静的リンクに変更して欲しい，というもの．レポートから 1 年半以上放置されていたので見かねて修正．
ちなみに Debian/Ubuntu/Fedora/Vineはこの辺まるっと無視して今も動的リンクしていたはず．ほんと静的リンク嫌いますよね……

1.4.1003.10x にてリリース．

GCC 4.7 環境での warning つぶし

Linux 向け修正．
タイトル通り．
1.4.1003.10x にてリリース．

ibus_engine_delete_surrounding_text 対応

Linux の IBus 環境向け変更．IBus の比較的新しい API である ibus_engine_delete_surrounding_text を使用して，確定取り消し・再変換を実装するというもの．これ以前は Windows のようにバックスペースキーイベントを送っていた．
ちょうど Firefox 側に関連バグが登録されていたのだけど，Mozc 側の問題ということで対処できた感じになる．

1.4.1003.10x にてリリース．

gtest なしでのビルドのサポート

openSUSE のパッケージで，Mozc が gtest に依存するのを独自パッチをあててまで回避しているっぽかったので，そういうことをしなくて良いように上流側で対処してみた，というもの．
1.4.1033.10x にてリリース．

compiler_specific.h 導入

コンパイラ依存コードの便利マクロ集．Chromium の同名のファイルにインスパイアされたもの．この頃から Clang 対応を考え始める．

1.5.1053.10x にてリリース

cURL 依存の排除

Linux 向け変更．
OSS Mozc ではネットワーク機能を一切有効にしていないにもかかわらず，ビルドに cURL が必要という状態だったので，cURL なしでビルドできるようにしたというもの．
1.5.1053.10x にてリリース

QTBUG-25536 対策

Qt QString::toUcs4() がサロゲートペア領域の文字に対してうまく動かない，という問題に対する Mozc 側のワークアラウンド．

const uint kData[] = { 0x10000 };
QString test = QString::fromUcs4(kData, 1);
const QVector<uint> ucs4s = test.toUcs4();
if (ucs4s.size() == 1) {
    qDebug() << "correct";
} else {
    qDebug() << "wrong";
}

このコード，最新の Qt 5.0.0 でも正しく動かない．ので，Mozc から QString::toUcs4() の呼び出しを削除する方向で対処．

1.5.1053.10x にてリリース

X11 Selection monitor

Linux 向け．
ibus-mozc が GtkTextView でしか再変換ができなかったのを，もうちょっと対応環境を増やした，という変更．
諸悪の根源は，Gtk IM Module の get_surrounding_text がしょぼいことである．この API，カーソル周辺文字列 + カーソル位置しか取得できない．アンカー位置が取得できないため，現在選択されているテキストというのが分からない状態で再変換を実装しなければならない．
今回とった workaround は，xcb-xfixes を利用して，X11 のセレクションイベントをモニターするというもの．セレクションイベント経由で現在選択されているテキストを記録しておいて，get_surrounding_text で取得された周辺文字列 + カーソル位置と比較し，矛盾がないように選択領域を再構築する．
xcb とかはじめて使ったのでなかなかにおもしろかった．

あと，このコードを書いているときに Linux 版 Firefox にサロゲートペア絡みのバグを見つけたので，Bugzilla に報告したところ，Mozilla Japan の中野さんに直して頂けました．感謝．

1.6.1187.102 にてリリース．

Mac OS X Lion でのビルド対応

対応したつもりになって 1 年近く放置してしまったバグの対処．

1.6.1187.102 にてリリース．

scim-mozc is removed

予告通り scim-mozc をリポジトリから削除．
直接の原因は内部のメンテナの不在．
まあ今更 SCIM もないでしょう．(Tizen を除く)

1.6.1187.102 にてリリース．

Debian-specific files are removed

Mozc のリポジトリに存在する Debian パッケージ定義ファイルがメンテナンスされていないので削除した，というもの．
ちょうど Debian 本家でメンテナンスされているパッケージ定義ファイルとの乖離が激しくなってきたところだったというのも理由のひとつ．

1.6.1187.102 にてリリース．

IBus 1.4.1 未満のサポート停止

IBUS_CHECK_VERSION マクロがあちこちに散らばっていたので，一カ所にまとめた上，旧バージョンのサポートと停止．だいぶコードが綺麗になる．

1.6.1187.102 にてリリース．

Clang 対応開始

Clang revision 159409 を使用して発生する warning を全て解消 (または suppress)．
1.6.1187.102 にてリリース．

Visual C++ 2012 対応

ちなちまとコンパイルエラーに対処．
1.6.1187.102 にてリリース．

#include <Windows.h> 撲滅運動

実に多くのヘッダファイルが不必要に #include <Windows.h> していることに気付きあちこち改良した，というもの．logging.h が <Windows.h> に依存するとかどうかと思う．

これでビルドがちょっとは速くなってくれるといいなぁと思いつつやったものの，目立っては高速化しなかった．残念．
1.6.1187.102 にてリリース．

Ack-less IPC

Windows の IPC レイヤの改善．いままでの IPC クライアントは，
1. メッセージ送信
2. 応答受信
3. Ack 送信
という手順を踏んでいたのを，3. でいきなり名前付きパイプを切断するように変更．切断イベントはどちらにしろサーバ側で検知可能なので，これを Ack イベントの代用とする．
実際これでレイテンシが数パーセント減ったのだから儲けものである．

1.6.1187.102 にてリリース．

StringPiece の移植

Mozc の portable library に StringPiece がないのが気になっていたので，えいやっと用意した一品．StringPiece については hamaji さんの解説記事 とか参照のこと．

1.6.1187.102 にてリリース．

テンキーにあるコンマに対応

Apple 日本語キーボードのテンキーには，ピリオドキーだけでなくコンマキーもあるのですが，これに対応できていなかったという問題の修正．
Mac では kVK_JIS_KeypadComma を使えば良いのですが，困ったのが Windows．
なんと Brazilian キーボードにはテンキーにコンマがあるらしく，その仮想キーコードは VK_ABNT_C2 (0xC2) とのこと．実際，Apple 日本語キーボードを Windows 7 につなげてテンキーのコンマを押してもこの仮想キーコードが返ってきました．互換性への執念恐るべし．
https://code.google.com/p/mozc/source/browse/trunk/src/win32/ime/ime_keyevent_handler.cc?r=124#253

  // The numpad comma on the Apple Japanese 109 keyboard is somehow mapped into
  // VK_ABNT_C2, which is only defined in kbd.h.
  // See also http://blogs.msdn.com/b/michkap/archive/2006/10/07/799605.aspx
  // See also b/6639635.
  KeyEvent::COMMA,                // 0xC2: VK_ABNT_C2

1.6.1187.102 にてリリース．

2012年他にやったこと - Mozc 編 - NyaRuRuが地球にいたころに続く．

Chromium に関しては 2012年やったこと - Chromium 編 - NyaRuRuが地球にいたころ に続く．

*1:ここでは OSS Mozc に限らず，いわゆる code-name Mozc についての活動