UnityからGNOME Shellへの切り替えと開発チームの取り組み
「Canonical」に勤める「Ubuntu Desktop」チームの開発者が、既存の「Ubuntu」ユーザーが「Ubuntu 17.10」へスムーズに移行できるようにするため、過去を振り返りつつ開発チームの取り組みを紹介しています。
「Unity」と異なり「GNOME Shell」は、「GNOME」プロジェクトが開発するデスクトップ環境です。
デスクトップ環境のデザインが変わるということは、ユーザーにとって使い勝手が変わることを意味します。
これは既存のユーザーに大きな影響を与えます。
また一方で、アップストリーム（GNOMEのこと）のソフトウェアに大きな変更を加えるということは、メンテナンスや品質の確保に相当のコストがかかります。
「Ubuntu」プロジェクトで「GNOME Shell」を丸々抱えるわけには行きません。
そのためアップストリームが決めたデザインの方針を尊重しつつ、既存の「Ubuntu」ユーザーが円滑に「GNOME Shell」へ移行できるよう、移行計画を練る必要があります。
この手法は、「Ubuntu Desktop」が過去に評判を得ていた手法です。
デザインの乖離をどう埋めるか、Unity時代の取り組み
「GNOME」のデザインと「Unity」のデザインは大きく異なっています。例えばヘッダーバーやメニューは、それぞれ異なるデザインを持っています。
「Ubuntu」では、デフォルトのアプリケーションの多くに「GNOME」のコアアプリケーションを採用しています。（Nautilusやgeditなど）
開発チームはこのデザインの乖離を埋めるため、どのような取り組みを行ってきたのでしょうか。
まずは「Unity」時代の取り組みを見てみましょう。
アプリケーションのメニューとヘッダーバー
「Unity」ではアプリケーションのメニューは、画面の上に配置されているグローバルメニューバーに表示されます。
Locally Integrated Menu（LIM）
また、ウィンドウのタイトルバーにアプリケーションのメニューを表示することも可能です。
ウィンドウのタイトルバーにアプリケーションのメニューを表示する仕組みを、「Locally Integrated Menu（LIM）」といいます。
「LIM」ではアプリのウィンドウを最大化すると、タイトルバーがグローバルメニューバーに統合され、アプリのメニューはグローバルメニューバーに表示されます。
これにより、画面のスペースを多く確保できます。
この動作は、「Unity」の洗練されたデザインの1つです。
ヘッダーバー
ヘッダーバーは、「GNOME」で採用されているタイトルバーに代わるデザインです。タイトルバー相当の機能を提供しつつ、ツールバーやボタンの配置などタイトルバーを拡張した機能を提供します。
トップバーとヘッダーバーの統合がうまくいかない
画面の上に配置されているトップバーとヘッダーバーとの相性が悪く、ヘッダーバーをトップバーに統合しようとすると、アプリの見た目が不自然な見た目になってしまいます。開発チームはヘッダーバーをなんとか統合できないか尽力しましたが、残念ながら致命的な問題が見つかりました。
LIMどうしよう？タイトルバーないんだけど・・・
「LIM」はウィンドウのタイトルバーにアプリケーションのメニューを配置します。一方ヘッダーバーにはそもそもタイトルバーが存在しません。
ユーザーから見るとヘッダーバーがタイトルバーのように見えますが、内部的にはヘッダーバーはタイトルバーではなく、独自のウィジェットです。
ヘッダーバーはタイトルバーと同様の機能を提供するため、ヘッダーバーが有効ならばタイトルバーを配置する必要がなくなります。
さてヘッダーバーを採用しているアプリのウィンドウではタイトルバーがないため、「LIM」の配置するメニューの場所が無くなってしまいました。
開発チームは、この問題を解決できませんでした。
GNOMEアプリケーションのメニューデザインの変更
ヘッダーバーに関連して多くのGNOMEアプリケーションは、メニューの提供方法を変更しました。今まで多くあったメニュー項目を減らし、最低限の項目をトップレベルのメニュー項目として提供するようになりました。
従来のメニューが提供していた機能へのアクセスは、ヘッダーバーに配置されているボタン等から呼び出すようになりました。
「Unity」のメニューデザインでは、ヘッダーバーを採用せず、従来通り多くのメニュー項目を表示し、ユーザーに機能を提供します。
メニューの提供方法の変更は、「Unity」のメニューデザインとは相反する変更です。
状況を改善するためGNOMEと連携して作業したが・・・
開発チームは、メニューのデザインなどそれぞれのデスクトップ環境に適合するデザインを実現できるよう、「GNOME」と連携して作業してきました。その作業の中には、うまく協調し実現できた作業もありました。
しかし「GNOME Shell」と「Unity」 の両方のデザインに適合するよう環境ごとに複数のUIを作成し、それぞれの環境をサポートしてもらうためアプリの開発者にその作業を求めるのは酷なことです。
アプリの開発者はこう思うでしょう。――そんなのは、うんざりだ
パッチを作ってアップストリームに送った
そこで開発チームは、そのような状況をサポートできるよう、アプリ向けにパッチを作成しました。アプリのアップストリームの開発者の中には、このパッチを受け入れてくれる開発者もいました。
しかしそれ以外の開発者は、パッチを受け入れてくれませんでした。
開発者自身が使用していない、あるいはテストしていないコードを受け入れたくないと思うのは、当然なことです。
アプリにパッチを適用した
そこで開発チームは、100%完璧な見た目にはならないとは言え、開発チームがアプリにパッチを適用し、開発チームでメンテナンスを行うことにしました。例えば「Ubuntu 16.04」の「Evince（ドキュメントリーダー）」では、ヘッダーバーがツールバーへと変換されています。
GNOME
Unity
開発チームにのしかかる負担
しかし開発チームを悩ませる状況が発生しました。開発チームを最も悩ませた事は、アップストリームで削られたメニュー項目を、従来のメニュー構造に戻すパッチのメンテナンスでした。
アプリの新バージョンを採用する度に、新機能や機能の変更に追従しつつ、合理的なデザインでメニュー項目の構造を決め、必要な実装を行わなければなりませんでした。
例えば「ヘルプ」メニューに「ファイルを開く」項目は相応しくありませんね。
この作業を開発チームが行っていました。
GNOME Shellへの切り替えと開発チームの取り組み
「Ubuntu 17.10」でデスクトップ環境が「Unity」から「GNOME Shell」へ変わります。もうパッチは必要ない
開発チームがメンテナンスしていたUIを変更するパッチは、もう必要なくなります。これからは「GNOME」のデザイナーや開発者が生み出したソフトウェアが、彼らが意図したとおりのデザイン及び機能で、「Ubuntu」ユーザーに届けられることになります。
ユーザーに最大限の配慮
「Ubuntu Desktop」には、非常に多くのユーザーがいます。既存の「Ubuntu Desktop」ユーザー、つまり「Unity」ユーザーは、「Unity」のデザインや使い方に慣れ親しんでいます。
開発チームは既存ユーザーに最大限の配慮を行い、「GNOME」へ切り替えた後も、既存のユーザーが満足して「Ubuntu Desktop」を利用できるよう、「Ubuntu Desktop」を確かなものにしたいと考えています。
ユーザーが必要とするもの
ユーザーが必要とするものは何か、あるいは何を必要としているのか。「Ubuntu 17.10」の開発において、機能やデザインを調整する期間はまだ残っています。
この過程において、「Ubuntu」がアップストリームの方針とぶつかってしまうこともあるでしょう。
しかしどうするのが正しいのか、それを把握するのは困難なことです。
以前「Ubuntu」ユーザーに対してアンケートが実施されました。
アンケート結果は、開発チームにとって非常に興味深いものでした。
特に多くのユーザーが強く望むGNOME Shell拡張は、そのGNOME Shell拡張が提供する機能相当の機能を、開発チームが何らかの方法で提供しなければならないという責任感を生み出すことになります。
どうやって実現するのか
開発チームは、ユーザーの要望をどうやって実現するのか。次の段階に必要なことは、アップストリームの「GNOME」と結論を議論し、それぞれの課題に対して解決策を見出すことです。
「Ubuntu」で挙げられた要望が、例えアップストリームから完全な賛成が得られなかったとしても、多くの場合「Ubuntu」で設定を切り替える実装を行い実現することは可能です。
現在開発チームは、アップストリームと実現性の可否及び実現方法について議論を行っています。
今月末に開催される「GUADEC」にて、より詳細な課題に関する議論が見られる予定です。
