2013-10-20

iBus 1.5はバグがあるからクソなのではない。設計上クソなのだ

先日、iBus 1.5がクソすぎると書いたが、以下によって、iBusをクソと罵るのではなく、貢献をしろという主張がなされている。貢献とは、ひとえにパッチを書いて送ることのみをいうのではない。問題の指摘や、使用した感想を報告するといった比較的軽いものも貢献に含まれると、そう主張している。

誰がオープンソースソフトウェアを酷いものにしてしまうのか - 人生が二度あれば

もちろん、それはそうだ。ソフトウェアは使われるというだけで貢献になる。利用感を報告すればなお良いし、開発に参加すればさらによい。しかし、それは貢献が受け入れられるならばの話だ。そのような貢献を受け入れる機会は10ヶ月もあったが、依然としてiBusの上流で受け入れる気配はみられない。貢献が受け入れられなければ、貢献は貢献にならないのだから、貢献をするのは無駄だ。

iBus 1.5の問題は、バグではない。設計上の問題である。そして、上流はその設計が正しいと信じていて、変える気配がない。

iBus 1.5には細かな問題がたくさんあるが、問題の本質は、設定UIにあるのではない。もっと本質的な、二つの独立した概念の混同にある。その概念とは、キーボードレイアウトと、IMEだ。混同というのは、iBus 1.5では、この二つの異なる概念が、統合されてしまったということだ。

キーボードレイアウトとは、キーボードというハードウェアからの入力に対して、どのキーにどのような文字、あるいは機能が割り当てられるのかというマッピングである。別に、ハードウェアの定義通りにキーボード入力を解釈する必要はない。あるキーが押されたら、どの文字や機能に割り当てるかというだけの話だ。

たとえば、ロシア語の書き下しに使われているキリル文字は、キーボードレイアウトを切り替えるだけで入力できる。ロシア語入力のためのIMとは、キーボードレイアウトを切り替えることである。これは、キリル文字というのは、せいぜい数十文字であり、大文字小文字はShiftキーの押し下げの有無などで表現できることを考えれば、キーボードのキーの数だけで入力可能だからだ。

ところが、Unicodeでは言語の頭文字をとってCJK(Chinese, Japanese, Korean)と呼ばれている言語用の文字では、単にキーボードレイアウトを変えるだけでは済まないのだ。この日本語を読めるなら分かるように、日本語には何万もの文字があり、日常的に使うだけでも、何千はくだらない。

しかし、現実に数千個ものキーをもつ入力装置を使うのは難しい。そのため、我々は日本語、中国語、ハングルを入力するのに、IMEを使っている。

キーボードレイアウトとしては、キーボードのキー数で入力できる、表音文字を割り当てる。例えばラテン文字だったり、仮名だったりする。

IMEとしては、受け取った入力を、別の文字に変換する。日本語や中国語の場合は、同じ入力に対して複数の候補があるので、文脈を考慮した賢い変換があることが望ましい。ハングルの場合は、表音文字なので、そのような文脈を考えた変換が必要ないと聞いている。

これを考えると、キーボードレイアウトとIMEは、全く別物であり、独立した概念であり、混同できないことは明らかである。キーボードからの入力を、キーボードレイアウトによって文字や機能にマッピングし、IMEによって変換するのだ。

iBus 1.5はこの根本的に異なる独立した概念を統合した。単に設定UIの問題ではない。今や、iBus 1.5では、キーボードレイアウトとIMEは同じ概念であり、同じスロットから切り替えていく。これはつまり、キーボードレイアウトとIMEを独立して設定できないということだ。

たとえば、英語入力には英語配列の直接入力を使い、日本語入力には日本語配列でIMEを使うといったことが、簡単にできなくなる。なぜならば、キーボードレイアウトとIMEの設定は統一されてしまっているからだ。独立して設定できない。

どうすればいいのかというと、iBus開発者の回答は、「Japanese(IME)のxmlをコピーして、編集して、別の名前をつけて、それを使え」というものだ。かれらはキーボードレイアウトとIMEが根本的に異なる概念であることを理解していないのだ。

貢献というか、意見報告は、すでに行われていた。10ヶ月もの時間があったのだ。

iBus 1.5は、なにも昨日今日にリリースされたのではない。2012年の年末にリリースされている。その後数ヶ月、freenode.netのIRCでは怨嗟の声が絶えなかったが、やがて消えてしまった。

私はUbuntuを使っているため、主要なパッケージのアップデートは、最低でも6ヶ月おきになる。そのため、iBus 1.5を体験したのは、Ubuntu 13.10にアップグレードしてからだ。

この手のソフトウェアを、手動で上流から落としてきて、ビルドして、インストールするというのは、実質不可能なのだ。なぜならば、システムを構成するソフトウェアは無数にあり、その全てを手動で更新し続けていくなど、狂気の沙汰だ。

そのため、自動化されなければならない。その自動化が、つまりはディストリビューションだ。Ubuntuは6ヶ月毎、あるいは2年毎のLTSリリースで、そのアップデートを一斉に行っている。これはUbuntuの方針だ。このために、Ubuntuは、あまりコンピューターに詳しくない者でも、使うことができる。

別の方針をとるディストリビューションもある。たとえば、GentooやArchといったディストロは、たえまなく上流を監視し、常にソフトウェアパッケーzのレポジトリを上流の更新に合わせ、またディストロ独自の変更も最小限にとどめるという方針をとっている。これにより、システムのパッケージを個別に、あるいは一斉に、いつでも、最新版にアップデートできる。これらのディストロのパッケージ管理システムはそれを踏まえたものになっており、特定のパッケージごとに設定できるので、あるパッケージは毎日アップデートするとか、あるパッケージは絶対にアップデートしないなどといった設定もできる。もちろん、これは管理するだけの知識が必要になるが、そのような知識をもっている人間には、GentooやArchは、無駄な手作業を省き、それでいてシステムを思うままに構築しやすい、理想のディストロなのだ。

というわけで、去年の年末にiBus 1.5がでたとき、即座にiBus 1.5を体験した集団がいる。ほとんどは、GentooやArchユーザーだ。freenodeは、このような初心者向けではないディストロのユーザーがたくさんいる。

今年のはじめ数ヶ月、iBus 1.5があまりにも使えないから、iBus 1.4に戻したとか、別のIMに切り替えたという声が目立った。聞けば、バグではなく設計がおかしい、開発者の思想がおかしいと言う。当時はその言葉の意味がいまいちよくわからなかったが、なるほど、キーボードレイアウトとIMEの統一(混同)は、たしかにおかしい。

彼ら、常にブリーディング・エッジなソフトウェアを恐れることなく使う兵達は、もちろん、貢献する。意見報告もすれば、パッチも送りつける。しかし、これは設計上の問題であって、iBusの上流はこの設計が正しいと信じているために、貢献は受け入れられないという。結局、彼らは古いバージョンのiBusに留まり、そしていずれは、別のIMに流れていく。fork? なんでわざわざiBusをforkしなけりゃならないのだ。世の中には上流がまともな思想をもつまともな設計のIMがごろごろしているというのに。

私はOS Xの事情はわからないのだが、どうもこれは、OS Xの日本語入力の仕組みを、形だけ模倣したのだという意見がある。

iBusがクソになった理由 — KaoriYa

考えてみれば、プログラムごとではなく、システム全体でIME状態を共有することになったといい、なにか異質なものを感じる。

5 comments:

  1. gentooはarchと使って最新版を追うわけではないです。
    標準で入るのは安定したバージョンになります。
    ibusなら1.4がgentooではstableですよ。
    ibus1.4が使いたいならgentoo使いましょう。

    ReplyDelete
  2. 使って→違って

    以下のサイトでディストリ毎のバージョンの違いがわかります。
    gentooがいかに慎重にバージョンアップをしているかわかると思います。
    archみたいに乱暴にバージョンを上げることは決してしません。
    http://oswatershed.org/

    ReplyDelete
  3. そうですよね、IBUS 1.5からさっさとskkinput/skkに移行しましょう。

    ReplyDelete
  4. Gentooのunstableなパッケージは結構な速度で更新されますよね?
    「個別に、あるいは一斉に……」以下の文章を読むと、そっちの話のように見えますね。

    そもそも、開発元のリポジトリからリリース前のコードを落としてきてコンパイルするようなパッケージがGentoo公式で提供されてることもあるし、Archより余程乱暴じゃあないですかね?

    ReplyDelete
  5. あー、窓のIMのあれか。確かにクソだ。

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.