GnomeがGTK +を使用し、KDEがQtを使用している場合、KDEアプリケーションをGnomeで実行できるのはなぜですか?
GTKとQtはどちらも、グラフィカルインターフェイスを構築するためのツールキットです。各UIツールキットは、ウィジェット(ボタン、テキストボックスなど)を作成するためのプログラムに独自の関数を提供し、グラフィカルプログラムがリンクするライブラリの形式で提供されます。 GNOME用に作成されたプログラムはGTK(libgdk
およびlibgtk
)を使用しますが、KDEプログラムはQt(libQtCore
およびlibQtGui
)を使用し、EnlightenmentプログラムはEFLを使用します。等々。
ただし、これらすべてのツールキットは同じ Xウィンドウシステム &同じ X11プロトコルを使用します。画面に表示するために、ツールキットは実行中のXサーバー(通常はXorg、以前はXFree86と呼ばれていました)に接続し、X11コマンド(ウィンドウの作成、ウィンドウに何かを描画)を送信し、X11入力イベント(マウス、キーボード、ウィンドウのサイズ変更)を受信します、&c)戻る。
(GTK、Qt、またはEFLなどのほとんどの最新のツールキットは、自分で空想的な描画を実行し、X11を使用してウィンドウ全体の完成したイメージを送信し、Xサーバーはそれを画面に表示するだけです。lXawやMotifなどの古いツールキットでは、代わりにX11は、線、長方形、テキストなどのプリミティブを描画し、Xサーバーがすべてのレンダリングを行います。)
その後、Xサーバーはすべてをまとめる、グラフィックカードと通信するなどの作業を行います。このように、最終的には同じOS機能を使用するだけなので、さまざまなツールキットのさまざまなバージョンを使用するプログラムを実行できます。
複数のツールキットの状況はXに固有ではありません。たとえば、標準のcomctl32
だけでなくWPFを使用するWindowsプログラムもありますが、 .NET WinForms、ChromeのAura、FirefoxのXUL、さらには同じGTKまたはQt。ほとんどのゲームは、独自のスタイルのコントロールを使用します。実際、これは、ウィンドウ全体に画像を描画できるanyグラフィックシステムで可能です。
しかし、 Xの原則 の1つは「ポリシーではなくメカニズム」でした。つまり、Xサーバーは、クライアント(グラフィカルプログラム)がさまざまなことを実行するためのメカニズムのみを提供しますが、必要なだけのルールを課します。言い換えれば、Xはこれを他のグラフィックスシステムよりもはるかに優れたものにします。
たとえば、グラフィックスシステムの不可欠な部分の1つはウィンドウ管理–各ウィンドウの周りのフレーム(別名装飾)の描画、ウィンドウの移動とサイズ変更の機能などです。オン。 WindowsとOSXにはシステムにウィンドウマネージャーが組み込まれていますが、Xでは別個のプログラムとして実行されます。X.Orgスイートには最小限のtwm
が付属していますが、ほとんどすべてのデスクトップ環境には独自のウィンドウマネージャーが付属しています( GNOMEにはSawfish、Metacity、gnome-Shellがあり、KDEにはKWinがあり、それぞれのデスクトップ環境との統合を提供しています。
(ツールキットと同様に、最新の「コンポジット」ウィンドウマネージャーは、実際にはすべてのウィンドウを最終的な画面イメージに合成するXorgの仕事を引き継ぎ、シャドウやエフェクトなどを追加できるようにします。)
最新のデスクトップ環境では、これも実際に問題を引き起こしています。最も一般的な例を使用するには:同じ「グラブキーボード」機能がホットキーで使用されます。ポップアップメニュー;とスクリーンセーバー、そして一度に1つのプログラムだけがそれを使用することができます。つまり、ポップアップメニューが開いている間は画面をロックしたり、画面がロックされている間は曲をスキップしたりすることはできません。これは、X11の後継としてWaylandが作成されているいくつかの理由の1つです。
技術的には、これは、Xプログラムを別のコンピューターで実行し、ネットワークを介してコンピューター上のXサーバーと通信できることを意味します。確かに、これは初期のprimaryユースケースであり、「Xserver」という名前の由来です。そもそも。 MacでXサーバーを実行し、Linux、FreeBSD、さらにはOpenVMSで実行されているプログラムによって作成されたウィンドウを表示させることができます。
ただし、前述のように、最新のツールキットはすべての描画クライアント側を実行し(X11プリミティブでは派手なグラフィックときれいなフォントを実行するのは非常に困難です)、最終的な画像のみをXサーバーにプッシュします。これはローカルで非常に高速ですが、ネットワーク帯域幅のかなりのビット。
(RFB(別名VNC)やMicrosoftの「リモートデスクトップ」などの他のプロトコルは、これのために設計されており、ウィンドウイメージを圧縮する非常に効率的な方法があります。)
答えの一部は、主要なデスクトップ環境(Gnome、KDE、XFCE、おそらく他のもの)が http://freedesktop.org の下で連携して、そのような相互運用を可能にすることです。 FD.oによって公開された仕様の1つは [〜#〜] ewmh [〜#〜] で、ウィンドウマネージャー間の特定のレベルの互換性を保証します(基本的なウィンドウ管理だけでなく、最新機能の場合) 。
GNOMEで実行する場合でも、KDEアプリケーションは依存する共有Qtライブラリを呼び出します。同じことが、他のデスクトップ環境でアプリケーションを実行する場合にも当てはまります。彼らは何を呼び出すことができるか、何ができないかに制限を課しません。