GNOMEとカスタムテーマ
過去数カ月間に渡り、「GNOME」におけるカスタムテーマの扱いに関する議論が行われました。
その内容が以下で紹介されています。
デフォルトのテーマとカスタムテーマ
GUIアプリは、デスクトップ環境で設定されているテーマに基づいたUIデザインでUIを表示します。「GNOME」は「Adwaita」というデフォルトのテーマを提供しており、デフォルトでは「Adwaita」に基づいたデザインでUIが表示されます。
「Adwaita」は「GNOME」が開発しています。
その一方でディストリビューションの中には、「Adwaita」とは異なる独自のテーマを開発し、そのディストリビューションのデフォルトのテーマとして採用しているディストリビューションもあります。
例えば「Ubuntu 18.04」では、デフォルトのテーマに独自の「Ambiance」を採用しています。
また「Ubuntu 18.10」では、デフォルトのテーマに独自の「Yaru」を採用しています。
加えてテーマを独自に開発して公開し、ユーザーにテーマを提供している人々もいます。
カスタムテーマとは、「GNOME」以外の開発者により開発されたテーマのことです。
そしてそれらのカスタムテーマが「GNOME」というエコシステムにどのような影響を与えるのか、議論が行われました。
考えの隔たり
この議論において、アプリの開発者やデザイナーとそれ以外の人々の間に、テーマに対する考え方に隔たりがあることが分かりました。現在のテーマの仕組みでうまく行くと考えている開発者を、未だ見たことがない。
その一方でアプリの開発者ではない多くの人々は、今のやり方でうまく行くと主張している。
今のやり方でうまく行くと主張している人々には、GNOMEの開発者が考える問題が正しく伝わっておらず、論点が噛み合っていません。
また非アプリの開発者は、テーマに関する問題に直面する機会がほとんどなく、また彼らはGNOMEの開発者が理由もなしにテーマに関する機能を削除したがっていると思っている、とのことです。
問題の根本
GNOME開発者が主張している問題の根本は、アプリを壊さずにアプリのデザインを自動的にそして大規模に変更できるかどうか、ということです。具体的に内容を見てみましょう。
テーマなんてものはない、あるのはただのCSSだ
多くの人々が持つ根本的な誤解は、「GTK 3」がテーマという仕組みをサポートしている、ということだ。これは正しくない。
「GTK 3」に明確に定義されたテーマAPIは存在しないからだ。
スタイルシート
あるのはCSSのスタイルシートであり、これはプラットフォーム及びアプリの開発者によってのみ利用されることを意図したものだった。プラットフォームスタイルシートはその意図を反映し、「Adwaita」と呼ばれている。
「Adwaita」とはサンスクリット語で「唯一（the only one）」という意味である。
カスタムスタイルシート
しかし主要なディストリビューションを含む人々の中には、テーマのハッキングに近い方法で長い間カスタムスタイルシートを使用している。以下の画像は古いバージョンのGRadioとUbuntuのAmbianceテーマを組み合わせたものである。
（左側にあるリストの文字がずれた場所に描画されている。）
CSSは巨大なAPIサーフェスであり、アプリ開発者とテーマ開発者の両者から使用されると、非常に簡単に両者の実装や意図が衝突する。
この結果、各アプリ及びテーマごとの組み合わせで手作業でテストを行い品質を保証しない限り、アプリの外観が崩れる問題につながる。
言うほど悪くないと、あなたは誇張するが
現状について最も不満に感じることは、ユーザーにとってテーマがほぼ期待通り動作しているように見える、ということである。サードパーティーのテーマは大部分にとって、デザインが崩れることなくそれなりに動作するが、ここかしこに細かな不具合が存在する。
例えばコントラストが不十分なボタン、アンダーラインとぶつかっている境界線/枠線、ローディング中を表す異様に大きいスピナー（ウィジェットのサイズが不適切）などである。
”そんな大したことじゃない”、とあなたは思うだろう。
しかしだ。
この状況における視点には、本当に重要な現実的な視点がいくつか抜けているのだ。
1.アプリ開発者の苦労
アプリの開発者は、カスタムテーマに起因する不具合を数多く修正している。なぜなら特定のディストリビューションでアプリのデザインが崩れる問題が発生した時に人々は、アプリの開発者に不満を言うためである。
そもそもアプリの開発者が全くサポートする気がない環境や設定のために、不具合の修正を無理に行っている現状がある。
アプリの開発者にとってそれは楽しいことではないのだが、アプリの開発者は不具合を修正しているのだ。
それはアプリの開発者が壊れたアプリをユーザーに提供したくないからだ。
2.新しい試みを避ける
アプリの開発者は、何か新しい革新的なものや視覚をアプリで実現しようとする取り組みを避けるようにしているのだ。他のスタイルシートとアプリを組み合わせると、それらは壊れてしまうことを知っているからだ。 （そして1.に繋がりかねない）
3.終わらない修正作業
テーマの開発者は、個々のアプリで発生する不具合を数多くスタイルシートで修正している。もちろんその作業は決して終わらない作業である。
新バージョンのアプリがリリースされるや否や、再び何かが壊れてしまう可能性があるからだ。（少なくともテストが必要）
GNOMEとエコシステム
さて上記の内容は、GNOMEにとってちょっとした作業に過ぎない。これはGNOMEが提供しているアプリの数が少ないためである。
もし仮にこの状況の中、数十のアプリを超えてGNOMEのエコシステムの拡大を期待するならば、各新しいアプリと共にテーマのメンテナンを行うことは持続性を失うことであり、この状況を変えなければならない。
壊れているとはどういうことか
アプリが壊れているとはどういうことか、壊れているという定義は何か。捉え方の違い
人々の中には、以下のようなアプリの壊れ方を受け入れられる人もいる。Date Pickerの例
Pop OSのテーマでは、カレンダーのDate Pickeの月と年の左側に、矢印が二重に表示されている。
ボタンの例
AmbianceテーマとNautilusの新規フォルダー作成画面の組み合わせでは、右上の作成（Create）ボタンが見えなくなっている。
geditの例
Pop OS上のgeditでは、ウィンドウの上部に茶色の四角形が飛び出しており、サイドバーの上部にあるウィジェットの見た目が理路整然としておらず、この環境では合理的なUXではない。
受け入れられない
私は上記の壊れ方をOKからは程遠いことであると考えている。アプリの開発者は、アプリのルック＆フィールを確実に適切なものにするため、そして不具合の修正やQA（品質保証テスト）の実行に多大な労力を払っているのだ。
（しばしばアプリが壊れる方法で）アプリを変更し、ユーザーに提供する前にQAを行わずディストリビューションを提供するディストリビューターは、アプリの開発者に敵対するものであり、どのような事情があってもそれは受け入れられるものではないだろう。
でもベストプラクティスに沿っている限りうまく行くって！
これは何人かの人々の間で共通の感覚になっている。アプリが頑張ればうまく行くのではないか
そして以下の議論に進むのだ。
もしアプリの開発者がベストプラクティスに従い、CSSの設定を使い、アプリのカラーをテーマカラーから派生しさえすれば、全てがうまく行くだろう。
この指摘の内容は重要なことであり、またその通りであり、加えてアプリの外観に関してアプリをより柔軟なものにすることができるが、問題全体の解決に結びつくものではない。
もしすべてのアプリがGTKが提供するデフォルトのコントロールのみを使用しており、非常に簡素なレイアウトであり、カスタムウィジェットやアプリ内にカスタムCSSを持っていなかったら、ベストプラクティスはアプリを破壊から守るのに十分だろう。
しかし現実はそうなっていないし、そのようなアプリばかり溢れる状況を望んではいないのだ。
ヒューマンインターフェースガイドライン
Human Interface Guidelines（HIG）は、ただのガイドラインである。そのため開発者は手作業で実装しなければならないし、開発者は時間の経過と共に変化及び発展させ、そしてあらゆるプラットフォームで動作する最良のアプリは、アプリの限界を押し上げ、新しいパターンを試し（時にはHIGに戻り）、アプリを洗練させていく。
この種の試行は、アプリを自動的にテーマに合わせた構成にすることは不可能であることを意味する。
見た目のデザインと対話のためのデザインは非常に密接に連携しており、もしあなたがアプリのスタイルを変えたいならば、ウィジェットの見せ方に関し具体的に考えられるデザイナーが必要である。
例えばPopテーマは、新しいフラットなNautilusのパスバーがどのように見えるべきか、どうやって把握すれば良いのだろうか？
それを自動的に行うことは不可能である。
それは新しいパターンだからだ。
これは稀なケースではなく、他のGNOMEコアアプリケーションでさえも同様である。
私が作業した多くのアプリでも、Nautilusのパスバーと同等のものを持っている。
アプリには様々なニーズがあり、時々独自のソリューションが要求されることもある。
そしてこの試みは、エコシステムにとって良いことなのである。
しかしまた同時に、自動的なアプリのデザインの再構成は不可能なことを意味する。
でもAdwaita DarkとHigh Contrastテーマについてはどうなんだ？
Adwaitaの派生であるAdwaita DarkとHigh Contrastは、GTK 3がサポートしている数少ないテーマのように見えることもあるが、技術的な点から言えばそうなのだが、見当違いである。技術的には異なるスタイルシートになるだろうが、これはただの実装詳細である。
これらのテーマとサードパーティーのテーマには明らかな違いがあるのだ。
1.ほぼAdwaita
これらはAdwaitaの実装に非常に非常に近しい実装であり、アプリを壊すことはまずない。2.プラットフォームの一部
これらは限られた数しかなく、またプラットフォームの一部である。これらは開発者が現実的にテスト対象及びサポート対象にできるものであり、なんらQAなしにすべてのアプリに乱雑なCSSをただ適用するだけのサードパーティー製のテーマとは完全に異なるものである。
3.デザイン言語の一部
これらはデザイン言語の一部であり、デザインの観点から適合させるための追加作業は、非常に少なくて済む。
もしあなた（アプリの開発者）が上記で述べたベストプラックティスに従っているのなら、何も作業しなくても済むケースも多々ある。
一貫性についてはどうだい？すべてのアプリの見た目を同じにしたいんだ！
一貫性という言葉は、テーマの議論においてよく聞かれる言葉である。しかし人によってその意味の捉え方は異なるようだ。
同じ色を使う（同じカラーリングにする）
ある人にとっては、”すべてのものは同じカラーを使うべきだ”ということを意味する。これはいくつかのアプリにとって割と簡単に実現できることだ。
例えアプリが使用しているツールキットが異なっていたとしても、あなたは単純にテーマを各ツールキットに提供すれば良い。
しかしこの一貫性は、非常に浅い一貫性だ。
QtアプリがAdwaitaのカラーを使っていると言うだけで、それが自動的にGNOMEプラットフォームに適合するわけじゃない。
UIパターンは重要な要素であり、テーマでUIパターンを変化させることはできない。
メニューバーを持っているアプリケーションをヘッダーバー持つアプリケーションに変化させる魔法なんて存在しないんだ。
真の一貫性
真の一貫性はデザインによってのみ実現可能だ。そしてアプリの開発者は、アプリの開発段階毎にデザインを構築し、そのデザインをアプリに取り込むことが必要である。
もしあなたが利用しているすべてのアプリの見た目を同じにしたいのなら、あなたの使用しているプラットフォームのHIGに沿って構築されたアプリのみを利用することだ。
テーマに関連する問題が起きた後にアプリを修正することは、あなたのシステムの一貫性を真に向上させるものではなく、それはアプリの開発者を大きく傷つけるものである。
でもユーザーはテーマが欲しいんだ！
ユーザーは多くのことを要望する。しかしあなたが欲しいといったところで、不可能なものを可能にすることはできない。
本件において重要なことは、個々のアプリ開発者の尽力とエコシステムへの影響の両面において、完全に自由な見た目をテーマに与えることは、それらに負担や犠牲が起こることを認識してもらうことだ。
カスタマイズ性とそれ以上のより優れたアプリという選択肢が与えられたのならば、大半の人々は後者を好むだろうと私は確信している。
我々は何ができるのだろうか？
何が問題なのかを共有する前に解決策について話し合うことは、あまり生産的なものではない。なので今のところ私は、問題及び問題の様々な側面をすべて把握することに関心の多くを割いている。
この問題に関しそれぞれ異なる視点を持つ様々な出資者がおり、物事を前に進めることは、いくつか難しい選択肢を生み出すことになるだろう。
今年開催されたGUADECでは、Theming & Ecosystem BoFで可能性のある方針に関し話し合いをした。
その方向で物事を前に進めていければと思う。
たとえ我々がどんなアイデアを思いついたとしても、アプリ開発者の必要性を真剣に受け止めていくことが大切である。
アプリ開発者は、あらゆるプラットフォームにとって必要不可欠な存在だ。
そして我々は彼らに十分な配慮を行ってこなかった。
我々のエコシステムを成長させたいなら、そして他の主要なプラットフォームと競うのであれば、その点を忘れてはならない。
