私はLinuxシステムのさまざまなコンポーネントがディスプレイサーバーが提供するサービスとどのようにやり取りするかを理解したいと思います。 Waylandベースのディスプレイサーバーで問題を複雑にする前に、まずX11に集中します。
- X11ベースのシステムに非常に基本的なGUIアプリケーションを実装するには、理論的には次のことを目指していることがわかります。X11用のCライブラリーバインディング特定のXクライアントを作成または作成するなど、
XMapWindow低レベルの基本要素を利用します。XDrawStringこれは、Linux実装の最低レベルでGTKやQtなどの一般的なGUIツールキットで使用されるAPIでもありますか？それとも、ボタンとテキストフィールドを別々に描画しますか？ - ~によるとこの投稿、ウィンドウマネージャの作業の1つは、ウィンドウの位置を制御することです。どうやってこれが起こったのですか？ディスプレイサーバーは、ウィンドウマネージャが表示したい各ウィンドウについて知っており、ウィンドウごとにウィンドウマネージャが場所と必要なサイズを提供することを期待していますか？たとえば、ウィンドウのサイズが変更されたときにこれらのサイズを更新するのはウィンドウマネージャの責任ですか？
- 上記の投稿をもう一度考えてみると、ウィンドウマネージャのもう一つの使命は、ウィンドウを飾ること、つまりアプリケーションの境界とコントロールを描くことです。ウィンドウマネージャはどのようにこれを行いますか？上記のX11基本要素を再利用して、実際のXクライアントの周りにオブジェクトを描画しますか？それでは、Xクライアント開発者がGUIにプログラムしたメニューが何であるかどうかをどうやって知ることができますか？
- ウィンドウマネージャだけでなく、デスクトップ環境全体（GNOMEなど）を実行している場合は、環境固有のコンポーネント（パネルやウィンドウスイッチャなど）を描画する方法は？別のXクライアントとして実行されますか？
最後に、X11の代わりにウェイランドを考えてみましょう。わかったらこの記事適切に言えば、Waylandベースのディスプレイサーバーは「Wayland Compositor」と呼ばれ、合成ウィンドウマネージャの機能を統合します。これは、MutterのようなWaylandコンポジターがCompizのような既存のウィンドウマネージャと完全に互換性がないことを意味しますか？
ベストアンサー1
ツールキットはもともとX11低レベルプリミティブを使用して画面にコンテンツを描画しました。現在のフォント処理とテキストレンダリングは、GLX（Xプロトコル経由のOpenGL）やDRI（Direct Rendering）などのXプロトコル拡張を使用してクライアント側で行われています。
Xサーバーはすべてのウィンドウとそのサイズと位置を知っています。ウィンドウはX11のサーバーサイドオブジェクトです。クライアントは X サーバにウィンドウ作成要求を送信でき、サーバは生成されるウィンドウの ID で応答します。 Windowsは通常、ユーザーがウィンドウマネージャと対話するときにサイズを変更し、ウィンドウマネージャはウィンドウサイズを変更するためにX11 API呼び出しを使用してサーバーに要求を送信します。
ウィンドウマネージャは特別なものですが、一般的なX11クライアントアプリケーションです。ウィンドウマネージャは、通常のXクライアントアプリケーションと同じX呼び出しを使用し、描画基本要素やポインタイベントなどの同じイベントを処理します。アプリケーションメニューは、ウィンドウマネージャが描く装飾の一部ではなく、アプリケーション自体で処理されます。
デスクトップ環境の「パネル」と「ウィンドウ切り替え」は、特にウィンドウ切り替えなどの操作を実行するときに別々のXクライアントまたはウィンドウマネージャの一部にすることができます。
Waylandウィンドウマネージャは、最も低いレベルのX11とは非常に異なります。なぜなら、WaylandアーキテクチャはX11とは非常に異なるからです。 Waylandを実行している場合は、Wayland Window Manager / Compositorが必要です。一方、一部のWaylandウィンドウマネージャ（KWinなど）は、ほぼ同じユーザーエクスペリエンスを提供するという目的で、元のX11バージョンを開始点として使用して作成されているため、ユーザーの観点から見ると、2つのバリエーション（KWin / X11互換）KWin /ウェイランドです。