Windows (Win32 API) と OS X (Cocoa) の両方に、ウィンドウ、イベント、およびその他の OS のものを処理するための独自の API があります。Linux に相当するものは何かについて、明確な答えを得たことは一度もありません。
GTK+ と言う人もいますが、GTK+ はクロス プラットフォームです。どうしたらネイティブになれるの?
Windows (Win32 API) と OS X (Cocoa) の両方に、ウィンドウ、イベント、およびその他の OS のものを処理するための独自の API があります。Linux に相当するものは何かについて、明確な答えを得たことは一度もありません。
GTK+ と言う人もいますが、GTK+ はクロス プラットフォームです。どうしたらネイティブになれるの?
Linux では、グラフィカル ユーザー インターフェイスはオペレーティング システムの一部ではありません。ほとんどの Linux デスクトップに見られるグラフィカル ユーザー インターフェイスは、X Window Systemと呼ばれるソフトウェアによって提供されます。このソフトウェアは、画面、キーボード、およびポインター デバイスを処理するデバイスに依存しない方法を定義します。
X Window は通信用のネットワーク プロトコルを定義しており、このプロトコルを「話す」方法を知っているプログラムであれば、それを使用できます。このプロトコルを使いやすくするXlibという C ライブラリがあるため、Xlib は一種のネイティブ GUI API です。Xlib は、X Window サーバーにアクセスする唯一の方法ではありません。XCBもあります。
Xlib の上に構築されたGTK+ ( GNOMEで使用) やQt ( KDEで使用)などのツールキット ライブラリは、プログラミングが容易であるため使用されます。たとえば、アプリケーション間で一貫したルック アンド フィールを提供したり、ドラッグ アンド ドロップを使いやすくしたり、最新のデスクトップ環境に標準のコンポーネントを提供したりします。
X が内部的に画面に描画する方法は、実装によって異なります。X.orgには、デバイスに依存しない部分とデバイスに依存する部分があります。前者はウィンドウなどの画面リソースを管理し、後者はグラフィック カード ドライバー (通常はカーネル モジュール) と通信します。通信は、直接メモリ アクセスを介して、またはカーネルへのシステム コールを介して行われます。ドライバは、コマンドをカード上のハードウェアが理解できる形式に変換します。
2013 年現在、Waylandと呼ばれる新しいウィンドウ システムが使用可能になり始めており、多くのディストリビューションがいずれそれに移行すると述べていますが、まだ明確なスケジュールはありません。このシステムは OpenGL/ES API に基づいています。これは、将来的に OpenGL が Linux の「ネイティブ GUI API」になることを意味します。GTK+ と QT を Wayland に移植する作業が行われているため、現在人気のあるアプリケーションとデスクトップ システムは最小限の変更で済みます。OS X が Xquartz を介して X11 アプリをサポートするように、移植できないアプリケーションは X11 サーバーを介してサポートされます。GTK+ への移植は1 年以内に完了する予定ですが、Qt 5 はすでに Wayland を完全にサポートしています。
さらに複雑なことに、Ubuntu は、Wayland で認識されている問題のために、Mirと呼ばれる新しいシステムを開発していると発表しました。このウィンドウ システムも OpenGL/ES API に基づいています。
Linux はカーネルであり、完全なオペレーティング システムではありません。Linux 上で実行され、ウィンドウを提供するさまざまなウィンドウ システムと GUI があります。通常、 X11は Linux ディストリビューションで使用されるウィンドウ システムです。
Waylandは、主に「将来の X11 キラー」と呼ばれているため、言及する価値があります。
また、Android やその他のモバイル オペレーティング システムには Linux カーネルがあっても X11 が含まれていないことにも注意してください。その意味で、X11 はすべての Linux システムにネイティブではありません。
クロスプラットフォームであることは、ネイティブであることとは何の関係もありません。Cocoa はGNUStepを介して他のプラットフォームにも移植されていますが、依然として OS X / macOS にネイティブです。
厳密に言えば、Linux の API はそのシステム コールで構成されています。これらはすべて、ユーザー モード (非カーネル) プログラムから呼び出すことができるカーネル関数です。これは、プログラムがファイルを開いたり読み取ったりすることを可能にする非常に低レベルのインターフェースです。一般的な紹介については、http://en.wikipedia.org/wiki/System_callを参照してください。
実際の Linux システムでは、グラフィカル ユーザー インターフェイスやその他の機能を提供するために、他のソフトウェアの「スタック」全体も実行されます。このスタックの各要素は、独自の API を提供します。
すでに述べたことを支援するために、次のブログに Linux グラフィックス スタックの非常に優れた概要があります。
これは、X11/Wayland などと、それらがどのように組み合わされるかを説明しています。すでに述べたことに加えて、Linux でグラフィックスに使用できる次の API について少し追加する価値があると思います。
Mesa - 「Mesa にはさまざまな機能がありますが、Mesa が提供する最も有名なものの 1 つは、その OpenGL 実装です。OpenGL API のオープンソース実装です。」
Cairo - 「cairo は、Firefox などのアプリケーションで直接、または GTK+ などのライブラリを介してベクトル形状を描画するために使用される描画ライブラリです。」
DRM (Direct Rendering Manager) - これはほとんど理解していませんが、基本的には、X を経由せずにグラフィックをフレームバッファに直接書き込むことができるカーネル ドライバです。
質問は「LinuxのネイティブGUI APIとは」に似ていると思います。
ほとんどの場合、X (別名 X11) が使用されます: http://en.wikipedia.org/wiki/X_Window_System。
ここで API ドキュメントを見つけることができます
XWindowsはおそらく「ネイティブ」と呼ばれるものに最も近いです:)
Linux カーネルのグラフィカル操作は、struct fb_ops として /include/linux/fb.h にあります。最終的に、これは X11、Wayland、または DRM などのアドオンが参照しているように見えるものです. これらの操作は、ベクターまたはラスターのハードコピーや tty 指向の端末デバイスではなく、ビデオ カード専用であるため、GUI としての有用性は限られています。必要に応じてシステムコールをバイパスするためにアセンブラを使用することを気にしないのであれば、グラフィカルな出力を得るためにこれらのアドオンが必要であるというのは完全には真実ではありません。
LinuxでWin32に最も近いのは、UIだけでなく、イベントや「その他のOS関連」についても言及しているlibcです。