The GNOME Journal の Issu #18 より、昨年は2009年の10月に開催された GNOME Boston Summit 2009 のいろいろなセッションの概要や話題についてまとめている「Jason Clinton 氏のメモ」を数回に分けて翻訳し紹介してみる (一部、原文にはないリンクなどを適宜挿入してある)。
その内容は、GNOME 3.0 や GLib/GTK+-3.0 などに関連した技術的なお話などが対象になっている。
ところで今回の原文は難解で、途中で主語が省略されたりでかなり手こずった 
。正直なところ読み物というレベルではないな、コレ (Natives は理解できるのかな)。
GNOME ボストン・サミット 2009
2010/02/05
Jason Clinton 氏が、昨年は2009年の10月に開催されたボストン・サミットで話し合われた内容について補足しつつまとめてくれました。
はじめに
毎年、
コロンバス・デイのある週末に、(主に北米に滞在する) GNOME の開発者らがマサチューセッツ州のボストンにて一同に会し、形式に縛られず自由なハッキングを楽しむイベントがあります。それは普段着で、そして和やかに進行していきます。この参加者は既に別の GNOME イベントで互いに顔なじみになっていることが多いです。イベントっぽい展示ブースはありません。たいていの企業は自分たちの従業員を参加者として派遣しているだけです。
今年のサミットは特に「実りの多い」話題や議論が多かったです。はっきりと、そして間近に迫った目標 (すなわち、GNOME バージョン3.0) があるので、参加者はみな自分たちの作業に没頭しているようでした。しっかりとまじめに議論が行われたため、議題からそれた話はほとんどありませんでした。アイディアはすぐに共有されて皆に知れ渡りました。そして見解の一致を受けて新しい目標が設定されました。おそらく今までの開催を含め今回のサミットで一番際だったのが結束力の現れでしょう: 今回のサミットでは、必要ならば、参加者はほぼ全てのセッションに参加することができる日程でした。
筆者は、本サミットの開催中と開催直後に自分が参加したセッションについての
メモ (規模は7,500語ほど) をいくつかブログに投稿しました。ここで紹介することはサミットの概要を短く要約したものです。但しセッションの結果そのものや、ある意味興味深い
factoid (疑わしさが残る事実) 関係は除いてあります。むしろサミットの内容をを「ストレート」に伝えると言うよりは、可能ならば複数のセッションをまとめたりして中身の濃い話にまとめてみました。
会場への移動
土曜日から始まった初日は、午前9:30くらいになるとサミットに出席する人達がケンブリッジの
MIT Sloan の建物の中へ移動し始め、Red Hat 社が用意してくれたベーグルやコーヒーやお茶を頂きながらセッション開始までのひとときを楽しんでいました (Red Hat はこのボストンに本社があり、サミットの主催者でもありました)。今年のサミットは、午前10:00に Red Hat の Jon MaCann 氏が議長を勤めた短いセッションから始まりました。このサミットの参加者は30分または1時間ほどのセッションに (頭のスイッチを切り換えながら) 順番に出席していきました。参加者は人気があるセッションが衝突しないよう確認し、それぞれのセッションで提案することを準備し、そして議論の末に到達した結果を票決するといった流れで、サミット前半の２日間のスケジュールを組み立てていました。そして、月曜日の最終日は終日ハッキングに当てられました。
“Plumbing” (フレームワーク)
GTK+ 3.0 とクライアント・サイドでのウィンドウ装飾
Matthias Clasen 氏は GTK+ 3.0 のために「現在あるAPIを意図的に分解し見直していこう」という計画と、バージョンの後方互換性の新しい機能について語ってくれました:
XInput2 や描画用 API、アプリケーションに手を加えることなくテーマ・エンジンを変更するといった機能など。まず最初の目標は、凝ったハッキングをあまり魅力的なものにしないこと、そして GNOME の新しいリリース毎に変更されてきた出来損ないのテーマ・エンジンの汚名を挽回すること、さらに上位のアプリケーションを安定して動作させるために充実したフレームワークを提供することでした。
Cody Russell 氏は「
クライアントサイドでの装飾」(
Client-Side-Decorations: CSD) という、既に別のブランチで開発が続けられている機能を話題にしました。彼の目標は現在の作業結果を GTK+ 3.0 にマージするということです。CSD を使えば GTK+ は、例えば Google の Chrome に搭載されているような
Tabs-In-Window-Decorator (ウィンドウの装飾としてタブを提供する) をサポートできるようになり、それにより GTK+ はウィンドウとウィンドウ以外の領域との間にある境界にテーマを導入することができるようになります (従来はウィンドウ・マネージャに全て委ねていました)。Cody 氏曰く、自分は Nokia と一緒に作業してきているので Qt と同じようなアプローチになるであろうこと、そして独自の CSD をそれぞれ提供している Qt と GTK+ のアプリケーションの間にある互換性の問題を回避することができるようになるとのことでした。これは、例えばアプリケーションがフリーズしても確実にウィンドウを終了しクローズできるようにするために、多くの人達が
EHWM の拡張について議論を行い、「ウィンドウを閉じる」というイベントを発行できる領域を指定できるようにしました。CSD の実装でウィンドウの大きさを変更できるイベントを処理できるようにすると、X11でウィンドウの境界線の描画が完了する前にそのウィンドウの大きさを変更しようとした場合の描画上の不具合を改善できます。一方、Glib 3.0 には特に大きな変更計画はありません。
Glib/D-Bus と GSettings
Ryan Lortie 氏は、まず始めに GNOME で D-Bus にアクセスするために提供されてきたいろいろなメソッドについて、その提供経緯などを簡単に語ってくれました。”gvariant” をベースにした “
gbus” は libdbus ライブラリの代替えでした。libdbus は dbus デーモンの中でも重要なプロトコルを実装したライブラリであり、glib や Qt、そして python などのバインディングが利用しています。また、とある２人のハッカーがそれぞれ別々に “gdbu” と “eggdbus” という実装を行っていたそうですが、これらの実装の完成度は十分ではなかったため、Ryan 氏はそれを改善するために３つの作業を提案しました。
- GVariant (D-Bus のデータ型の１つ) を Glib へマージする
- libgio と libdbus1 をリンクさせる (おそらく GIO のモジュールの拡張ポイントを利用することで実現可能)
- “gbus” と “eggbus” から妥当な実装を抜き出して、GDbus 型として GIO のライブラリへマージする
Colin Walters 氏の要請に応じる形で、このステップに従って実装された新しいバインディングがフィルタリングとパス登録を得るだろうことで意見が一致しました。さらにセッションの参加者らは GIO の中に libunique を (新しいバインディングの上位として) マージすることについて同意してくれました。
それから Ryan 氏は Glib の GSetting とその API のデモを行いました。GSettings はちょうど GConf の代替えとして提案されていたメカニズムでした: 今現在は了承済になりました。このセッションの参加者は、GVariant を Glib にマージした後に、GSettings のメカニズムも GIO へ追加することを希望しました。GSettings は、複数の設定を一度に変更するといったイベントに対して発行されるアトミックなシグナルを利用します (複数の設定変更に対してそれぞれシグナルを発行するのではなく)。GSettings のシグナルは再帰では発行されることはなく、受け取ったシグナルをフィルタリングできる機能の計画もあります。GSettings のスキーマは普通のテキストファイルです (書式は python のようにインデントとコロンを使います)。GSettings は継承をスキーマの表現としてサポートしています (「スキーマの継承」)。
Ryan 氏は GConf の代替えである dconf のデモを行いました。それから簡単な API について説明してくれました。従来の GConf と dconf を比較するとデータの読み取りだけで 10〜50 倍高速であり、同様にデータの書き込みも高いパフォーマンスがあるとのことでした。dconf のメモリ使用量は GConf よりも「かなり小さくなる」(magnitude smaller) よう設計されているだけでなく、書き込み処理の時にだけメモリを使用するようになっています。dconf によるデータの書き込みでは fsync() 関数を大量に使用していますが、アプリケーションの処理をブロックすることはないので気にしなくても良いでしょう。
dconf を利用しているアプリケーションのテスト (主にデグレードしているかどうかの確認) を行う際は、まずユーザのデスクトップ・セッションに影響しないようプロキシを設定するか、あるいは独自の GSetting プラグインを利用して dconf のリクエストを一時的に使用する作業用のデータベースへ転送するという方法があります。さらに Ryan 氏は、まもなく dconf に PolKit のサポートが追加されることを発表しました。
ディストリビュータがパッケージを作成する場合、GNOME オリジナルのデフォルト設定を自分達のポリシーに従って上書きすることが多いですが、それについても Ryan 氏は、(標準のデフォルト・データベースを無視して) ベンダ独自のデフォルトのデータベースをシステムに追加するよりは、パッケージにパッチをあてることでデフォルトのスキーマを変更する方法を提案しました。
最後に、セッションのまとめで少しだけ補足がありました。NFS 経由のホームディレクトリを持つユーザが dconf を使うと問題が発生することがあります。一般的に NFS 越しに mmap() 関数を呼び出すことに問題があるからです (mmap() 関数はそのような利用を想定していない)。Ryan 氏はその問題にも着手しており、解決方法を見つけることを約束したそうです; GConf からの移行を説明したドキュメントを含め、dconf の API リファレンス・マニュアルもまもなく library.gnome.org にアップロードされる予定です (訳注:翻訳時現在は既に「dconf Reference Manual」として公開済でした)。GConf と dconf とのブリッジの作成もまた作業中だそうです。このブリッジは簡単なアプリケーションを実行できますが、まだ解決しなければならない重要な問題が残っているようです。Ryan 氏は、また、まだまだ皆さんの助けが必要であることを参加者に訴えていました (特にブリッジの問題)。
Hallway Track: GTK+ のフォント・ダイアログの改良
休憩時に通路で催されたセッションの中で、Alberto Ruiz 氏と Máirín Duffy さんのチームはフォント・ダイアログのユーザビリティ改善について語ってくれました。Máirín さんはいくつかのモックアップを用意し、Alberto 氏はそれを pygtk を使って実装してくれていました。そしてそれらのプロトタイプを使ってユーザビリティのテストを実施して見せてくれました。彼らはこの１週間以内に最初のプロタイプを公開することを約束してくれ、数日後には Máirín さんがモックアップとプロタイプのいくつかと、コメントを書き込むページを公開してくれました。
GObject イントロスペクション
Colin Walters 氏はセッションの冒頭で GObject introspection を簡単に紹介してくれました。彼は自分の意見として、GObject は既にイントロスペクションを導入できる段階にきていると語りました。イントロスペクションのツールを導入するにあたり、GObject の型システムは既にたくさんの必要条件を満たしています (Ｃ言語のライブラリを作成しやすくしてくれる設計になっているおかげで)。とはいえ、イントロスペクションを実現するにはこれ以外にもいろいろなものが必要でした – 大部分はアノテーションの機能です。これを受けて、Colin 氏はＣ言語のライブラリにメタデータを付与し GObject イントロスペクションからそれらのライブラリにアクセスする方法をデモしてくれました。このアノテーションのデータは、例えばどのポインタによって何のコンテナが渡されたのか、そしてそれが完了した後にアプリケーション側でポインタを破棄する必要があるのかどうかなどを定義します。
GObject イントロスペクションのツールには *.gir という XML ファイルに記載されたアノテーションを解析するパーサがあります。その *.gir というファイルをコンパイルして *.typelib というファイルを生成します。このファイルには解析したアノテーションと同じ情報がバイナリ形式で格納されます (読み込みの効率が良いので)。その後にプログラミング言語のバインディングを呼び出します。言語バインディングはいろいろ用意されており、GJS という Javascript のバインディングも利用できます。PyBank という GObject イントロスペクション・ベースの Python バインディングがあります (訳注: PyBank は PyGI という名前になったので、これ以降は PyGI と記述します)。このバインディングは完成当時は問題ありませんでしたが、いくつかの呼び出し規則の中に互換性に対して解決しなければならない課題があります。Colin 氏は従来の古いバインディングを置き換えるべきではないと考えていました。新しいバインディングは PyGI を利用すべきで、PyGI は古いバインディングと新しいバインディングとの間にある互換性を維持することになるとのことです。
Colin 氏は、gtkdoc ツールにアノテーションのデータを理解する機能が追加されることを期待していましたが、そこまで到達する前にすべき作業がまだいくつか残っているようです。最後に彼は GObject イントロスペクションのプロジェクトの中で複数の言語が混ざったプログラミングに挑戦するという提案を上げました: GObject を使うだけで既にその 85% は完成していると言えるのではないでしょうか。
Clutter バージョン 1.2 の API
このセッションでは「Clutter のバージョン 1.2 に追加して欲しい API」について話し合いました。Emmanuele Bassi 氏が視覚効果を含む新しい機能を上げてくれました: Texture Atlasing (複数の小さなテクスチャをまとめて大きなテクスチャを生成する技法) や統一規格に則ったテクスチャのキャッシュ、レイアウト管理などがありました。彼はモジュール式のプラグイン・アーキテクチャを追加して入力メソッドを扱えるようにしたいという考えも披露してくれました （このプラグインは GIO が使用しているものに似ています): すなわち、継承したクラスの中で API スタブを実装できるようにするということです。これにより、GtkModules 経由で追加された全ての機能を ClutterModules 型のモジュールの中で再実装することができるようになります。
今度のバージョンはパフォーマンスも注目に値するそうです。フレームバッファ・オブジェクト上で処理することで、変更のあったウィンドウを部分的にそのオブジェクトへアップロードすることができるので更に効率が良くなるであろうとのことです (例えば、Evolution の Throbber がアニメーションしている時は、再び Evolution のウィンドウ全体をフレームバッファ・オブジェクトにアップロードする必要はありません。テクスチャで変更のあった部分だけをアップロードすべきです)。但し、どれだけ効率が良くなるのかといったデータの提示はありませんでした。多くの人達がバグだらけのハードウェアの上に OpenGL で作ったウィンドウ・マネージャをのせ、その上でアプリケーションが正しく動作するように VSync の値を取得することに取り組んでいました。問題はハードウェアのドライバの奥深くに横たわっていましたし、まれにハードウェアそのものに問題があったとのことです。ユーザがクリックしたオブジェクトを探し出す性能を改善する方法について３つのアイディアが提案されました。
さらに、特別なことを考えずに Clutter と GTK+ とが共存できればよいとか、いろいろな種類のアプリケーションを対象にして欲しいとか、GNOME で Clutter を完全にサポートして欲しいとかという提案に議論が移ろうとしているのを感じ取ったところで、彼はセッションを終了しました。可能な限りコードを共有し、各ツールキットに対するユーザビリティ・ガイドや API リファレンス・マニュアル、プログラミング・ガイドを提供してもらえれば、私たちはハッカーは Clutter と GTK+ で作ったアプリケーションを一緒に組み合わせることが可能なプラットフォームをいろいろ提供することができるようになるのですが。
という感じで読みながらなんとか日本語の文章にしてみたけど、かなり面倒なので、もしかしたら次回の翻訳はないかもしれません
。
nautilus-renames-1.9.90.tar.bz2: Release Candidate1
。
)。