Mikeforce::OldBlog

GNOME の バージョン 1.0 系から使っている「息の長い」画像ブラウザ。
単独プロジェクトから始まった後に GNOME プロジェクトに加わり、新しいバージョンの GTK+2 にも対応してきた gThumb は、画像ビューアというよりは複数の画像をまとめて閲覧するファイル・ブラウザみたいな位置づけから始まったアプリだった (そもそもファイル・ブラウザである Nautilus があまりに貧弱だった時代でもあったので)。さらに１個の画像を表示する画像ビューアとは異なり、「複数枚からなる写真」を対象にしていた視点がよかった。たとえば、いろいろな場所に格納した複数の画像をカタログという仮想的なアルバムを使って関連付けたり、USB ストレージやデジタル・カメラなどの外部のデバイスから画像を取り込んだりと (当時のファイル・ブラウザにはない) なかなか便利な機能が簡単に利用できたので、他にも魅力的なアプリがいろいろあったけど、今でも gThumb を常用している。

このアプリ、最近バージョンがアップグレードしたということで、パッケージをビルドしてインストールしたみたら、そのメイン・フレームが大きく変わっていて驚いた。ほぼ全ての機能が拡張機能としてモジュール化されており、必要な機能を必要な時に有効にするスタイルになっている。なので、初めてインストールした時は何も有効になっていなかったのでちょっととまどったけれど :

拡張機能は従来のものに加え、今風にクラウド対応したり、さまざまな条件で画像を検索したり、なぜか楽曲や動画の再生なんかもできるようになっているのはデジタル・カメラとの接続を意識してのことか。デスクトップの仮想ファイルシステムでサポートしていれば、もちろん iphone4 といったスマートフォンもマウントしてカメラ同様に参照できる。
とはいえメッセージの翻訳状況はこれまた大変な状態になっていたけど、昨日なんとか完了し commit しておいた。

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 氏はそれを改善するために３つの作業を提案しました。

1. GVariant (D-Bus のデータ型の１つ) を Glib へマージする
2. libgio と libdbus1 をリンクさせる (おそらく GIO のモジュールの拡張ポイントを利用することで実現可能)
3. “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+ で作ったアプリケーションを一緒に組み合わせることが可能なプラットフォームをいろいろ提供することができるようになるのですが。

---

という感じで読みながらなんとか日本語の文章にしてみたけど、かなり面倒なので、もしかしたら次回の翻訳はないかもしれません 。

The GNOME Journal の記事より、残っている課題の多さからリリースが遅れ、さらに G30 のリリース持ち越しにも影響を与えることになった GNOME シェルの紹介。
「ユーザはデスクトップに気を遣いながら使う」といった旧態依然の概念 (呪縛?) から卒業する時がやっと来たかという感じ。ここでスクリーンショットには実際にベータ版を使いたかったけど、開発版のライブラリをインストールしている自分の環境では Ubuntu 版はどうもうまく動いてくれなかった 。

---

超かんたんで素敵な GNOME シェル
– 開発メンバの Marina Zhurakhinskaya が紹介する GNOME シェルの概要とそれが目標としていること –
GNOME シェルは新しい GNOME の「顔」と言えます。このプロジェクトの目標は、今のデスクトップよりももっとましな設計思想を持つルック＆フィールと、その主要な機能をゼロから作り上げることにあります。そのような機能の中には、アプリケーションやドキュメントなどを見つけ出して起動したり (または開いたり)、いろいろな状態を切り替えたり、あるいはチャットのアプリケーションで受け取ったメッセージや株価の変動などを表示できるようなことが含まれています。それらの多くは、既存の GNOME デスクトップを構成するいろいろなモジュールで別個に実現されている機能ではありますが、GNOME シェルではそれら複数のモジュールを１個の大きな設計思想の中に統合したものになっています。
筆者は GNOME UI ハッキング大会 (Hackfest) に参加して、GNOME シェルの概念を設計するフェーズから作業しているハッカーの１人です。この大会は2008年10月の「GNOME ボストン・サミット」が開催される前の週に開かれました。筆者の作業には、コードの作成やスケジュールの検討、GNOME シェルをテストするための情報や本プロジェクトに参加する際の参考情報を wiki にまとめたり更新するといったことが含まれています。また、筆者はソフトウェア開発チームの一人であり、そして RedHat を紹介するプロジェクトのデザイナの一人でもあります。これらのチームは、GNOME シェルがお手本としている (Clutter や Mutter、そして GObject Introspection といった) プロジェクトのメンバら、そして実際にこのプロジェクトに貢献してくれるコミュニティのメンバらと一緒に積極的に作業を推し進めています。ご存じのように、GNOME シェルのお試し版的なパッケージがいろいろな Linux ディストリビューションからリリースされていますし、きたる GNOME のバージョン3.0ではデフォルトで取り込まれる予定になっています (現在のところリリースは2010年9月)。
GNOME シェルの設計を開始したきっかけは、ユーザのデスクトップで日常的に発生する作業 (Task) に基づいて、自動的に学習し進化していくようなユーザ・インタフェースを提供できるようにしたいということでした。時間を追う毎に、ユーザはデスクトップの使い途を広げていけるようにしなければなりません。例えば、高度な機能を順を追って見つけやすくしたり、パタン化した自分たちの作業や個人的な嗜好をデスクトップに反映させることで、よりユーザ個人に特化したデスクトップを組み立てれるようにする必要があるでしょう。ユーザがこれまで使用してきて習得した情報や経験 (いわゆる User Experience) をまるまる面倒みてやるということ以外にも、先進的なグラフィックス技術を活用し見た目にも豪華な視覚効果でユーザに楽しんでもらおうという目的もあります。さらに、ユーザのために他の作業の優先順位を落として、ユーザの好みに応じたイベントの通知をフィルタリングし、現在の作業 (とそのために利用しているアプリケーション) にフォーカスを当てやすくすることができればよいのではと考えています。

GNOME シェルで、まず最初に目をひく部分は、GNOME バージョン2.x で提供されていた２個のパネルが１個のパネルで置き換えられているということです (これは画面の上端におかれている黒いパネルのことです)。このパネルには、お馴染みの時計や通知スペースといったオブジェクトが配置されていますが、アプリケーションや設定などを含んだGNOMEメニューが１個のボタンで置き換えられているのがお分かりでしょうか (画面の左上端にある「Activities」というボタンで、このボタンをクリックすることで「アクティビティ概要モード」(Activities Overview Mode)に入れます)。これがユーザに「アクティビティ」(現在の作業) の概要を知らせてくれるボタンになります。その隣にあるのが、実際のアクティビティに関連づけられているボタンでアプリケーションの名前が付いています。最終的にはアプリケーション専用のメニューや設定オプションの他に一般的な (アプリケーションを終了したり、新しいウィンドウを開いたりする) オプションなど用意される予定です。GNOME バージョン2.x で提供されていたパネルに配置されていた、いろいろなコントロールが無くなったことで画面全体が広くなりましたし、あまり使用する機会のないオプションや現在の作業で利用しているアプリケーションとは関係のないオブジェクトがなくなってすっきりしました。ユーザがアプリケーションを切り替える方法は、従来の [Alt]+[Tab] キーで表示されるダイアログを改良した方法が採用されています (このダイアログには起動中の全てのアプリケーションが表示されるようになっています)。

GNOME シェルで一番重要で革新的な部分は「アクティビティ概要モード」(Activities Overview Mode) です。これは現在の作業から新しい別の作業へデスクトップ画面全体を利用しながら切り替える操作です (複数個用意されています)。このモードでは、ユーザが開いたウィンドウや起動したお気に入りのアプリケーションをプレビュー表示したり、ユーザのホーム・フォルダやコンピュータに接続されているいろいろなデバイス (「場所」(Places) としてまとめられています) や最近開いたドキュメントなどを、現在の状況に応じて表示してくれます。さらに、ユーザが望めば検索機能とウェブ閲覧機能を統合することもできます。
ユーザはパネルにある「Activities」ボタンをクリックするか、あるいは単にマウス・カーソルを画面の左上端 (「ホット・コーナー」と呼びます) に移動するだけでアクティビティ概要モードに切り替えることができます。このホット・コーナーは素早く簡単にアクティビティ概要モードにアクセスする方法を提供してくれます。

GNOME バージョン2同様に、デスクトップにあるいろいろなウィンドウは「ワークスペース」に結びつけて管理することができますが、GNOME シェルのアクティビティ概要モードではそれ以上に直感的なワークスペースを作成してくれます。ユーザは、現在ワークスペース上にある全てのオブジェクトを簡単に参照することができ、新しいアプリケーションやドキュメントを特定のワークスペースにドラッグして、そのワークスペースで起動したりオープンしたり、あるいは複数のウィンドウをドラッグしながらワークスペースとワークスペースの間を移動させることができます。ユーザはデフォルトで１個のワークスペースを所有しており、必要に応じて追加したり削除することができます。直感的なワークスペースを作成できる機能の以外にも、全てのワークスペース上にあるオブジェクトの一覧を表示する機能を使えば、ユーザが以前と同じワークスペースで作業をしていたかどうかに関係なく、目的のアクティビティがあるワークスペースに１回の操作で切り替えることができます。同様に、[Alt]+[Tab] キーで表示されるダイアログの中でも１回の操作でワークスペースを切り替えることができます (このダイアログの中には全てのワークスペースに配置しているアプリケーションの一覧が表示されます)。
GNOME シェルでは、アプリケーションが持つウィンドウを１つ１つ管理するというよりは、アプリケーション本体 (Firefox だとか Evolution だとか端末だとか) に注目するような設計になっています。アクティビティ概要モードの中で表示されているアプリケーションのアイコンにはアプリケーションを起動するランチャの役目と、アプリケーションが実行中かどうかのステータスを通知する役目があります。この機能は、例えば GNOME バージョン2でパネルの中に配置されていたアプリケーション・ランチャや「ウィンドウの一覧」アプレットに相当します。一覧表示されているアプリケーションの中で、現在実行中のものはそのアプリケーション名の背後からスポットライトで当てたような光が付与されて表示され、もしアプリケーションが複数のウィンドウをオープンしているのであれば複数の丸い光が表示されるようになっています。この一覧にあるアプリケーションのアイコンをクリックすると、未だ起動されていないのであれば新しいアプリケーションのウィンドウがオープンされ、もし既に実行中であれば最後に使用したそのアプリケーションのウィンドウに切り替わります。

タブ付きのウェブ・ブラウザの場合をとりあげみると、タブが開かれているかどうかに応じてそのウィンドウのタイトルや外観が変わります。例えば Firefox という名前とアイコンを強調表示させることで、「アプリケーション (Activity) を切り替えて使う」という一貫した GNOME シェルの目的 (機能) を実現しています。さらにアプリケーションのアイコンを右クリックすると、そのアプリケーションがオープンしている全てのウィンドウのプレビューが表示されるようになっています。これは、GNOME バージョン2のウィンドウの一覧アプレットを使って最小化したウィンドウを元の状態に戻す際にどのウィンドウをクリックすればよいのか迷ってしまうくらい「みすぼらしいインタフェース」と比較して、かなり改善されているのが分かります。新しいウィンドウをオープンする際のオプションは、現在のウィンドウのタイトルを右クリックして表示されるメニューから利用できます。同様に、[Alt]+[Tab] キーで表示されるダイアログではアプリケーションがオープンしている複数のウィンドウをグループ化して表示し、アプリケーションのアイコンを選択するとウィンドウを大きくプレビューしてくれます。
XChat IRC や Empathy、Evolution、電卓、チェスとったアプリケーションの場合、それらのインスタンスが１個だけしか起動されないことが保証されているので、アプリケーションが既に実行中であればユーザが想定していたウィンドウに切り替わるようになっています。それに対し GNOME バージョン2の場合だと、ウィンドウを切り替える前に目的のアプリケーションを起動していたかどうかを知っておく必要があります。間違って同じアプリケーションを２個起動してしまう、例えば電卓を２個立ち上げてしまった場合は不要なアプリケーションのために貴重なデスクトップ領域が狭くなってしまうとか、IRC で2回もログインしてしまうといったつまらない問題が発生する可能性がありました。アプリケーションの起動と切り替えをまとめて管理し、デフォルトの操作では実行中のアプリケーションの複製に切り替えるようにすることで、アプリケーションのアイコンをクリックして作業を進めるという流れにおいて、ユーザに対し妥当な (期待した) 振る舞いを保証することができるようになりました。
GNOME シェルは気軽に試してみることができます。現在の開発ステータスとしては、比較的安定した開発バージョンを気軽に利用できる状態でリリースしており、多くのユーザに使って貰っています。また、いろいろな Linux ディストリビューションでもプレビュー版の GNOME シェル・パッケージが利用できます。
Fedora 12 の場合であれば:

# sudo yum install gnome-shell

してから GNOME メニューから [システム]->[設定]->[デスクトップの効果] を選択して表示されるダイアログで GNOME シェルを選択してみて下さい。
Ubuntu 9.10 の場合であれば:

# sudo apt-get install gnome-shell
# gnome-shell --replace

を実行します。さらに:

# gconftool-2 --set /desktop/gnome/session/required_components/windowmanager --type string gnome-shell

しておけばログインする度に GNOME シェルが利用できるようになります。また:

# gconftool-2 --unset /desktop/gnome/session/required_components/windowmanager

するだけで上で変更した設定を元に戻せます。
パッケージを利用する代わりに、jhbuild というシンプルなビルド・ツールを使って、GNOME シェルのソースをビルドして実行し、定期的に最新の開発版にアップデートすることもできます。
そして、できあがった GNOME シェルを起動する前にその「カンニング・ペーパー」(使い方) を確認しておいて下さい。
現在の開発状況ですが、その作業アイテムには新しいメッセージ通知スペース (Message Tray) とその通知システムの開発だとか、アプリケーションやドキュメントの閲覧機能の改善、GNOME シェルを拡張するプラグインを開発するための開発キットの導入などが追加されました。これらの機能に対する設計や開発に対するヘルプは大歓迎です。プロジェクトのメーリング・リストに登録したり、IRC を使って irc.gnome.org の #gnome-shell チャンネルに合わせるなどして本プロジェクトに是非参加して下さい。あるいは、本プロジェクトの開発ページにある設計書を読んで詳細を理解したり、メッセージの翻訳に協力したり、Bugzilla でバグの報告やバグの修正に貢献するといったタスクもあります。ご自身が貢献したいことやヘルプが必要であれば前述の IRC チャンネルで問い合わせてみて下さい。隠れていろいろやって貰っても構いません！
原文の筆者について
Marina Zhurakhinskaya は RedHat のデスクトップ・チームで、次世代の GNOME シェルの開発を行っているシニア・ソフトウェア・エンジニアの１人です。彼女は主に GNOME デスクトップが直感的にユーザの要望に応答できているかどうかを確認したり、プロジェクトに貢献してくれる人達のためにドキュメントをまとめておく作業を行っています。職場の外では、友人や家族とブラブラして時を過ごしたり、旅行へ行ったり、オーディオブックを聴いたり、Yelp や TripAdvisor や Amazon のレビューを読んでいます。