以前の投稿「 気になる Ubuntu マルチタッチインターフェイス」の続き。
Ubuntu 10.10 ネットブック版のタッチ実演動画がだそうで。
http://blip.tv/file/4245457
Linuxにおけるこの分野の開発の加速に Canonical が乗り出してくれたのはうれしいです。
あと、Novell/Suse の takashi iwai さんのおかげで、Synaptics ドライバの ClickPad 対応が開発元の方に取り込まれ始めてるみたい。
ClickPad は HP の Mini 210などに採用されてるようですね。
Multi-Touch For The X.Org Synaptics Driver
そんな状況のなか、先月、フランスのトゥールーズ（航空宇宙産業の街らしい）でX開発者サミットが開催されたそうなんですが、マルチタッチに関するワークショップも２日間に渡って開かれたとのこと。
Peter Hutter さんがその概要や自分の考えをブログに綴ってます。
Thoughts on Linux multitouch
ハードウェア方面からは仏Stantum社の人や Wacomの Ping Cheng女史、ソフトウェア方面からは Canonical の Chase Douglas氏（Wacomドライバの新Bamboo対応に関わっておられるので感謝。Ubuntu 10.10 には間に合いませんでしたが、近いうちにLinux カーネルでの Bamboo P&T 正式対応が来るでしょう。）や Nokia の Qtツールキット担当の人などが参加されたそうです。
Hutter さん曰く、
マルチタッチで一番難しいのは、ユーザー側の意図とシステム側で受け取るデータとの間の食い違い。
例えば、絵描きアプリケーションにおいて、一連のデータ・イベントがあったとする。
- 色選択ツール上に１点のタッチが現れ、赤色を選択後、タッチは消える。
- 色選択ツール上に1点のタッチが現れ、緑色を選択後、タッチは消える。
- キャンバス上に２点のタッチが現れ移動する。
上のようなデータの流れが生成される原因として考えられるシナリオは次の通り。
- １人のユーザーが誤って赤色を選択、緑色を選び直した後、両指とも緑色で描画している。
- １人のユーザーが１番目の指で赤色を選択、次に２番目の指で緑色を選択した後、各指それぞれ選択した色で描画している。
- １人のユーザーが１番目の指で誤って赤色を選択、その指で緑色を選び直した後、緑色で描画、２番目の指は事前に割り当て済みの別の色で描画している。
- ２人のユーザーがそれぞれ別の色を選択して同時に描画している。
しかし、データの流れからだけでは、こうした判別は不可能。
ユーザー側の意図とデータとのこうしたミスマッチによって問題が発生してしまうことがないようにするのは、もっぱら UI デザイン部分での挑戦。
AppleのiPhoneの場合、マルチタッチ対応アプリが１つだけ全画面で開くから、非常に限定的な設定環境、そのような設定を持ち込むには新しいAPIが１つだけあればいいので、技術的観点からは容易（もっとも、出来のよいAPIを作るのは大変な仕事）。
一方、Xサーバへのマルチタッチ対応の組み込みで最も問題なるのが、既存のデスクトップ環境のサポート。
マルチタッチは複数ウィンドウの複数アプリにまたがって正常に働かなければならず、加えて、マルチタッチ非対応アプリも利用可能なように従来型のポインターをエミュレーションすることも必要になる。
このような機能を提供する商用製品は個人的にまだ見たことがない。
Microsoft Surfaceアプリでさえ、非常に限定された設定内でこれをエミュレーションしてるだけ。（iPhoneやiPad、Surfaceテーブルは所有してないので、開発に進展があったとしたら、見逃してる可能性はあるけれど。）
我々は、アプリ開発者に対して、既存のものを捨てて、マルチタッチ対応するように書き直すよう単純に求めることはできない。Android や Apple はその気になれば可能。
マルチタッチ・インターフェイスと非マルチタッチ・インターフェイスとの間の移行コストをゼロにするためには次の４つが要求される。
- あらゆるマルチタッチ対応アプリで働くマルチタッチ
- 複数アプリに同時に働くマルチタッチ
- 非マルチタッチ対応アプリのためのポインターエミュレーション
- マルチタッチ・アプリと従来型ポインター/キーボード・アプリの同時実行への対応
マルチタッチに言及すると、すぐにジェスチャーの話が持ち上がる。
ジェスチャー認識はタッチ認識の邪魔になってはいけない。
例えば、システムがジェスチャーを待つためのタイムアウトを取っていても、ユーザーはジェスチャーのつもりがなく、待ち時間を設けることが無意味な場合がある。
つまり、ジェスチャー対応の組み込みは、単にいくつかのジェスチャーを定義して終わるものではない。定義されたジェスチャーのなかから適切なものを選択することがユーザーに対して遅延として表出しないようにするのも重要。
一方、FOSSソフトウェアのスタックは細かく分離してしまっているので、真のマルチタッチ統合はウィンドウマネージャやデスクトップ環境、アプリケーションに渡って行われる必要がある。
自分が間違っていることを望むが、Ubuntu Unity のジェスチャーサポートでもっとも懸念するのは、そのジェスチャーが別の部分といくつかのケースで重複してしまい、ユーザーの体感に悪影響をもたらすこと。
Xサーバにおけるマルチタッチ対応について、当初は現在のイベントシステムにマルチタッチを統合することを考えていたが、それは放棄した。
今の目標は、新しいイベントを追加して、それをポインター＆キーボードのイベントと併存させること。
したがって、クライアント側でマルチタッチ・イベントに対応させる修正作業が必要になる。すでに XInput2 に対応しているクライアントであっても同様。
ただし、これらは未だ流動的な状況。
多くの人にとって興味があるのは、こうしたもの全てが Ubuntu のマルチタッチ対応とどう一緒になるのか、ということだろう。
Ubuntu のジェスチャー対応の試みは賞賛に値するが、自分の考えでは、真のマルチタッチはジェスチャー以上のものであり、その観点からすると、かなり限定的なものに映る。
その現在の UI は、マルチタッチに完全に適合したデスクトップを目指すよりも、Apple Magic Trackpad のような、ジェスチャーが従来の入力の上乗せとなっているデバイスの方を目標にしているようである。
マルチタッチ・アプリケーションが少ない現状では妥当だが、システムレベルのデザインのためには、中長期のことも念頭に入れる必要がある。
Ubuntu側が最初に提案した X Gesture Extentions は、ジェスチャー認識部をXサーバに入れようとするもの。これでは、システムに認識部が１種類だけしか存在し得ない。
我々は完全な唯一のウィンドウマネージャやツールキットを追い求めてはいないが、それは認識部においても当てはまるだろう。
Canonical の Chase とワークショップでも検討し合い、結果として X開発者サミットは、もはやXサーバに認識部を持ち込むことを求めていない。
新しいアプローチでは、純粋にクライアント側で、ライブラリやデーモンによってジェスチャー認識が行われる。
複数の異なるジェスチャー認識が同時に併存可能。（GTK, Qt, Mozilla 等々が思い浮かぶ）
これが UI にとって良いことかどうかはまた別の問題で、特に Wacom の Ping Cheng は一貫性の面で不安のあるシステムを持つことを良く思っていない。
これについて、我々はデスクトップ環境とツールキットとの間で共通の土台を見出す必要がある。
Geis (Gesture Engine Interface and Support) はそこに踏み込むものなのだが、まだ開発は初期段階であるし、問題なのは、Geis の実装に著作権管理契約(Copyright Assingment)を要すること。
Geist自体は適切なアプローチで必要なものなのだが、政治的判断がからみ、進展しなくなってしまうことが心配。
ジェスチャーインターフェイスのような中央的なものは、ツールキット開発者やX.Org開発者、アプリケーション開発者などが協働して開発すべきで、著作権管理契約の必要性は捨て去ることを提案したい。
えーと、なにがなんだかわかりませんが、とにかくマルチタッチ環境の整備が来年一層進みそうだなってことで。 (;^_^A
