Budgie その25 - GNOMEとGTK+から脱却・Qtへ移行

GNOMEから脱却

「Budgie」は「Ubuntu Budgie」で採用されているデスクトップ環境です。



「Ubuntu Budgie」は「Ubuntu 17.04」にて公式フレーバーになり、「Ubuntu Budgie 17.04」が「Ubuntu 17.04」と共に初めてリリースされます。

そんな「Budgie」ですが、現在は「GNOME」の中に「Budgie」を構成するコンポーネントが統合されている状態です。

この状況が次期メジャーリリースである「Budgie 11」で大きく変わります。
「Budgie 11」の目標の1つに、「GNOME」からの脱却が挙げられています。

• Explaining the deGNOMEing

元々Budgieは、GNOMEアプリケーションとの統合を目的としたものだった。
その結果としてGNOMEスタックに完全に統合されるに至った。
しかし統合できたものの、非常に高いコスト（負担）がかかることになった。

時の流れと共にGNOMEは改良され変化し、GNOMEがメジャーリリースされる度にBudgieで問題がおき、修正しなければならなかった。

この状況はBudgieが最初にベースとしたGNOME 3.10からGNOME 3.22までずっと続いている。

GNOMEのAPIやABIの変更の有無にかかわらず、GNOMEのコンポーネントは他のコンポーネントに影響を与え、多くのテーマやウィジェットに非互換が発生した。
GdkScreen APIはもはや同じように機能しないし、GSettingsの再配置可能なスキーマの挙動が原因で発生するsegfaultでさえも状況が変わりつつある。

知っておいて欲しいのだが、この内容はGNOMEを侮辱したりコケにすることを意図したものではない。
プロジェクトに起きている問題を説明したものであり、心からGNOMEに敬意を払っている。
GNOMEは構想や展望を持っており、彼らはそれを実現しようとしている。

しかし残念ながらそれは、複雑なBudgieのプロジェクトにとってGNOMEのコンポーネントの再利用を困難なものにしている。

もっとシンプルなプロジェクトでは、GNOMEスタックの部分的な再利用は何の問題もない。

しかしソフトウェアが巨大化し、深いところにある設定や構成の変更、マルチパネルのサポート、安定したABIの導入、そして動的なアプレットをサポートするため適切なプラグインAPIシステムを取り入れようとすると、あっという間に入り組んだ構造になる。

Qtへ移行

様々な問題に対処するため、将来を見据え「GNOME」だけでなく「GTK+」からも脱却し「Qt」へ移行するとのことです。

「Qt」の他に「EFL/Enlightenment」も移行先の候補に上がっていましたが、「EFL/Enlightenment」は外観を「Budgie」のデザインに合わせるには膨大な作業が必要であり、またそのAPIは「GLib」にも似たひどい問題を抱えているため「Qt」への移行に決定されました。（独自のboolean型やマクロベースで記述されたmain()関数など）

なぜGTK+ではないのか

「GTK+」はGNOMEデスクトップと親和性のあるツールキットを目指して開発していることが明らかであり、上記の問題の解決には十分ではないためです。

レイアウトの制約

「GTK+」ではウィジェット等を配置するレイアウトシステムにひどい制約があり、ウィジェットの位置やサイズを遅延キャッシュする仕組みは、リアルタイムのアニメーションや子ウィンドウベースのパネルの配置を困難なものにしています。

これを効果的にカスタムレイアウトで実現するには、大量のboilerplateが必要になります。

非公開のAPI

ここ数年「GTK+」に追加されたGTK+ CSSノードのようなAPIは、外部の開発者がアクセスできないAPIであり、「GTK+」内で完結してしまっています。

「Wayland」のウィンドウを配置する仕組みでは、GtkPopoverがGtkWindowと内部的にプライベートな関係を持っており、外部から手を出しにくい状態です。

「Budgie」はデスクトップ環境を構築するにあたり、グラフィック、画面効果、OpenGL、シェーダーなどの分野においてより強力なツールキットを必要としています。

言語はC++へ

「Qt」自体「C++」で構成されたライブラリーであり、現在「Vala」で記述されている部分も「C++」等他の言語へ移行します。

「Vala」は「GNOME/GTK+」向けに最適化された言語であり、「C++」ライブラリーを利用できません。

QMLは使用しない

「QML」は利用しません。
デスクトップのコア部分は「JavaScript」を使用せず、「C++」のみで記述します。

ただしこれは、サードパーティーが提供するウィジェットに適用する制限ではありません。

KDEライブラリーは使用しない

「Qt」といえば「KDE/Plasma Desktop」なのですが、KDEライブラリーは使用しません。
Plasmaとの互換性を提供する目的はないためです。

アプリは引き続きGNOMEコアアプリケーションを使用

アプリは引き続きGNOMEコアアプリケーションを使用します。

デザインは変更しない

デスクトップのデザインは変更せず、大きく使い勝手が変わるようなことはしません。

Qtを採用するデスクトップ環境が増える

「Ubuntu」やフレーバーに目を向けると、「Qt」を採用するデスクトップ環境が増えつつあります。


今まで「GTK+」一色と言っても良いほど「GTK+」を採用したデスクトップ環境ばかりでしたが、状況が変わりつつありますね。

「Kubuntu」は元々「Qt」を採用していますが、今後「Qt」へ移行予定もしくはその可能性があるOSは以下のようになります。

• Ubuntu
• Lubuntu
• Ubuntu Budgie