*NIX システムで GUI が機能する理由について詳しく知りたいのですが、どこから調査を開始すればよいかよくわかりません。私の理解では、すべてのビジュアルを可能にするのは X サーバーであり、その上に KDE、Gnome などのさまざまな UI 環境があります。
しかし、たとえば、私は常に、特定の UI 環境で実行すると、その環境を使用するプログラムに制限されると考えていましたが、Gnome で KDE ユーティリティとソフトウェアを使用できることに気付きました。環境。
このトピックについて学び始めるには、どこから始めるのがよいでしょうか?
ポールの答えは少し専門用語が多いかもしれないと思うので、ここに私の試みがあります.
多数のディスプレイ デバイス (VGA モニター、コンポジット ビデオ、HDMI など) があり、これらはハードウェアで直接処理される傾向があります。専用のグラフィック プロセッサ (GPU) で。
アプリケーションがこのハードウェアと直接通信するのではなく、ドライバー(オペレーティング システム カーネル内にある) を使用します。ハードウェアごとに異なるドライバーが必要ですが、OpenGL などの同じインターフェイスを使用して、すべてのドライバーに命令を与えることができます。
App --OpenGL--> Driver --> Hardware --VGA--> Screen
もちろん、ほとんどの標準と同様に、実際にはさまざまな標準がたくさんあります。OpenGL は、ほとんどのオペレーティング システムのほとんどのドライバでサポートされています。その「OpenGL ES」サブセットは携帯電話でうまく動作し、OpenGL 命令に基づいて画像を作成できる「ソフトウェア ドライバー」があります (実際の OpenGL サポートよりもはるかに遅いですが、すべてのドライバーで画像を描画できます)。OpenGL の大きな競合相手は DirectX ですが、これは Windows と XBox でしか機能しません。
OpenGL へのレンダリングは、フルスクリーン 3D ゲームのようなものには問題ありませんが、*NIX グラフィックス システム (「X」として知られている) は、それに加えて、複数のアプリケーションを同じ画面に描画する機能と、ネットワークを介して描画する機能という 2 つの主要な機能を提供します。これを行うには、サーバープロセスが画面に描画し、アプリケーション (「クライアント」) が「X11 プロトコル」を使用してこのサーバーと通信します (「11」は単なるバージョン番号です)。
App A ----------OpenGL-------+
|
App B --+ |
| |
+--X11--> X server --+----> Driver --> Hardware --> Screen
|
App C --+
|
...network ...
|
App D --+
X は OpenGL よりも長く使用されているため、ドライバーに直接アクセスする傾向がありますが、それはそれほど重要ではありません。
X11 プロトコルは、アプリケーションが描画を許可されているウィンドウを作成することによって機能します。X は、これらのウィンドウを画面上に配置したり、それらを重ねたりすることができます。OpenGL を使用するアプリケーションは、コマンドを X を「パススルー」してドライバに直接渡すことができ、X は他のアプリケーションと同様にウィンドウを配置します (これは X11 のネットワーク機能をバイパスするため、ネットワーク経由では機能しません)。
通常、ウィンドウマネージャーと呼ばれる、ウィンドウの配置、非表示/表示、および閉じる専用のアプリケーションがあります。必要に応じて、ウィンドウ マネージャーは、タイトル バーを描画したり、ハンドルのサイズを変更したりできるように、他のウィンドウの周囲にいくつかの薄いウィンドウを作成する場合があります。
X11 プロトコルには、形状の描画、フォントのレンダリングなどのコマンドが含まれており、xtermプログラムやtwmウィンドウ マネージャーなど、これらを直接使用するアプリケーションがあります。
xterm --+
|
+--X11--> X --> Driver --> ...
|
twm --+
ただし、最新のアプリケーションのほとんどは、生の X11 は退屈すぎると感じています。線や形状を描画する代わりに、ウィジェット全体(ボタン、メニュー、アイコンなど) を描画します。これを行うために、ツールキットが作成されました。最も有名な 2 つは、QtとGTK+ (GIMP ツール キット、もともと GIMP 用に作成されたため) と呼ばれます。他には、Motif、Lesstif、ETK、Tk、FLTK などがあります。ツールキットにボタンの描画を依頼すると、ツールキットはボタンの描画に必要なすべての X11 コマンドを送信します。さらに、サイズと位置を処理し、何かが重なっている場合は描画を更新してから移動し、コードに通知します。ボタンがクリックされ、一部のツールキットでは、ウィジェットの外観を変更することもできますテーマ。一部のツールキットはクロスプラットフォームでもあるため、Linux では X11 コマンドを送信し、Windows や OSX などでは異なるコマンドを送信します。
Rhythmbox --> GTK+ --+
|
GIMP --> GTK+ --+
|
Amarok --> Qt --+--X11--> X --> Driver --> ...
|
Skype --> Qt --+
|
aMSN --> Tk --+
一部のツールキットは、他のツールキットよりも優れた機能を提供します。たとえばwxWidgets、Qt で描画を行い (Linux では、Windows と OSX は「ネイティブ」)、XULFirefox で使用され、GTK+ を使用して描画を行います。
Audacity --> wxWidgets --> Qt --+
|
Firefox --> XUL --> GTK+ --+--X11--> X --> Driver --> ...
|
GIMP ----------------> GTK+ --+
言及すべき重要な点は、X11 の形状およびテキスト描画コマンドは、非常に原始的であるため、実際にはあまり使用されないということです。多くのツールキットは実際にウィジェットを画像としてレンダリングし、X にそれらの画像を描画させます。新しいWaylandシステムは、描画コマンドを捨て、アプリケーションとツールキットが OpenGL を直接使用できるようにすることで、X を置き換えようとしています。
GNOME や KDE などのさまざまなデスクトップ環境と、それらが連携するかどうかについて言及されました。これらは基本的に、連携して動作するように作成されたアプリケーションの大規模なコレクションです。GNOME アプリケーションはすべて GTK+ で作成されているのに対し、KDE アプリケーションはすべて Qt で作成されています。
上記の図の矢印を見ると、各 Qt アプリケーションが X と個別に通信し、各 GTK+ アプリケーションが X と個別に通信する、などがわかります。Qt と GTK+ アプリケーションが並行して動作できるだけでなく、X に関する限り、それは 2 つの Qt アプリケーションまたは 2 つの GTK+ アプリケーションと同じです!
デスクトップを混在させるときに心配する唯一のことは、2 つのアプリケーションが同じ仕事をするために競合しているかどうかです。たとえば、2 つのウィンドウ マネージャーまたは 2 つのデスクトップ パネルを実行しようとしている場合です。これはグラフィックやツールキットなどの問題ではないことに注意してください。同じツールキットで構築された 2 つのデスクトップを使用すると同じ問題が発生するためです (たとえば、lxpanel と gnome-panel は両方とも GTK+ で作成されていますが、それでもお互いのやり方で！）
基本的に、GUI ビットはクロム (プログラムのウィンドウ周辺のもの) を含む個別のライブラリであり、通常はデスクトップ ツールバーなどの他の要素が多数含まれています。GNOME と KDE は、このデスクトップ環境の例です。
それぞれにウィンドウ マネージャーが含まれています。ウィンドウ マネージャーは、クロムを描画する場所と描画方法をプログラムに正確に伝えるビットです。
それらの下には、ウィンドウ マネージャーが画面に描画するために使用する API を提供する X フレームワークがあります。したがって、X は、ハードウェアとの対話方法を指示するグラフィックス ドライバーに依存します。
ウィンドウマネージャの上には、実際のプログラムがあります。これらのそれぞれは、ウィンドウ マネージャーを呼び出して、「閉じるボタン付きの 50x50 ウィンドウをください」などの一般的なことを行います。
プログラムによって描画される実際のウィジェットは、通常、GNOME に含まれているようなグラフィック ツールキットを利用します。KDE には Qt ツールキットが含まれています。
ここに wm の良い選択がありますhttp://xwinman.org/