#x window system

What is Mac X11

X11およびXQuartzはXプログラム（この場合大抵はLinuxのGUIアプリケーション）をMac OS X上で動作可能にするためのソフトウェア。アップルは当初からMac OS XにX11.appを提供しており、よりコミュニティーベースにするために後にコミュニティー版のXQuartzのインストールリンクをダミーのX11.appに機能として持たせた。

これはX11及びXQuartzを提供することにより、LinuxのアプリケーションのバリューをMac OS X上でも装備およびユーザーが利用できるようにしたということである。ジョブズはもともとUNIXやLinuxのアプリケーションが有用であり、Mac OS X上で移植して利用できるようにすべきというメリットがわかっていたからこのような戦略をとった。

Apple A/UX 3 1 1 on a Macintosh IIci Demonstration

この記事ではLinuxやUNIX系のアプリケーションをMac OS Xに移植するためのXQuartzプログラムについて記述したい。XQuartzプログラムはLinuxのGUIアプリケーションがLinux上で動作するときに出力及び入力の最も低レベルなところを担うX Window SystemグラフィックサーバーをMac OS XのネイティブなグラフィックサーバあるQuartzにトンネルしてエミュレートして動作させ、LinuxのGUIアプリケーションのMac OS Xへの移植を簡便化するためのソフトウェアである。昔はAppleが提供していたためX11というアプリケーションだったが、現在はオープンソースコミュニティが開発しているためそのコミュニティー版のことをXQuartzと名付けている。

XQuartzはアプリケーションバンドル内にフレームワークとして配置する方法も考えられるが、もともとグラフィックサーバーをトンネルするというシステム的な役割を果たすプログラムなので、これは別個のプロセスにしたほうが正しいだろう。

通常LinuxのアプリケーションをMac OS Xに移植するならウィジェットツールのレイヤーでトンネルしたほうがより普通で正しい移植だが、グラフィックサーバーのレイヤーでトンネルして移植することに依ってより移植にかかる手間を省き、容易に移植できるようにしている。このグラフィックサーバーのレイヤーで移植するというのは単純な見方をするなら簡便な移植を実現するための互換性的な手法とは言える。

アプリケーションを移植するならば本来それぞれのモジュールの直接に対応するレイヤーでトンネルして移植すべきなので、GUIならウィジェットツールのレイヤーで移植すべきである。X Window Systemはウィンドウごとに領域が作られるので、グラフィックサーバーでトンネルする手法はルートレスなウィンドウ表示でも有効と言えるが、しかしグラフィックサーバーのレイヤーで移植するというのはシステム的なレイヤーと言えるし、これは厳密にはアプリケーションではなくグラフィックサーバーのトンネルをシステム全体で実現している手法と言うのが厳密なところである。つまり実際のところはXQuartzはアプリケーション個体を移植するためのものではなく、システム全体でシステム内で動作するXプログラムが利用するX Window Systemの出力をネイティブなグラフィックサーバーであるQuartzにトンネルしてエミュレートして環境として動作させるためのものと視るのが正しい。これはLinux的な見方をするならばシステムモジュールのトンネルに当たるので当たり前とは言える。

本来はXQuartzプログラムが必要とされた場合に自動で起動して必要なくなった時に自動で終了する方が良いと考えられるが、XQuartzを利用するプログラム自体はDockアイコンを持たないものもあるし、Xプログラムを起動するためにXQuartzをランチャとして使いXQuartzのインターフェイス上のメニューからプログラムを起動することもあるので、XQuartzはDockにプロセスアイコンを表示する仕様のほうが良いだろう。つまりこのインターフェイスはデスクトップ環境の役割としてのグラフィックサーバーであるX Window Systemへのアクセスも担っている。なのでアプリケーション表示もそれぞれのアプリケーションの名前をシステムのメニューバーに表示するのではなく、XQuartzとしてX11と表示するほうが正しいと考えられる。Linuxにおいてはパッケージとして動作することに当たるのでXQuartzは（ある意味ただの）バックエンドのプロセスになるものだが、アプリケーション方式で扱ったほうがMac OS X上のプログラムとしては使いやすいだろう。

XQuartzアプリケーションはウィンドウシステム自体が違うのでウィンドウのタイトルバーにXのアイコンを表示することも正しい仕様だと思われる。モジュールをトンネルすることはLinuxにおいては珍しいことではないが、Mac OS XにおいてはQuartzをグラフィックサーバーとして利用することが当たり前なためこの表示は正しいかもしれない。

XQuartzは特にGTKアプリケーションでよく移植のために使われるが、Cocoa-GTKが実用的ならばこちらを使うほうがより正しい環境統合である。なのでより簡便に作れるXQuartz版を先に開発した後にCocoa-GTK版を余力があれば作れば良い。

Cocoa-GTK版はシステムのグローバルメニューバーにアプリケーションのメニューが統合されるが（ちなみにCocoa-GTK版のアプリケーションは大抵メニュー内のテキストフィールドからヘルプを検索できるようだ）、これはアプリケーションを適合させるときに環境統合用の改造を加える必要があるということでもある。本来簡便な移植でLinuxアプリケーションをそのまま動作させたい場合はLinux同様にアプリケーションウィンドウ内にメニューを表示させたほうが良いので、XQuartz版においてはアプリケーションウィンドウ内でメニューを表示させたほうが良い。XQuartz版においてもXQuartzとGTKを改造してLinuxのUnityデスクトップ環境のようにウィンドウ対応のメニューをウィンドウごとに切り替えてグローバルメニューバーに表示させる方法はあり得るが、移植が容易なのはアプリケーションウィンドウ内にメニューを表示させるほうの手法である。

Feonix CCD Enterprise for Apple OS Xにおいても、（Cocoa-GTKでない）GTKアプリケーションやXアプリケーションを採用したプログラムにおいてはXQuartzは移植のために有効だろう。設計がいくらか環境統合されているGTKプログラムならば、GTKのAquaテーマを被せればシステムの外観との調和が取れると思われる。

プログラムやシステムを移植したければCPUとメモリとファイルシステムとグラフィックサーバーとオーディオサーバーをネイティブなシステムにトンネルすればいい。実際の現状のシステムにおいては、CPUを移植するとはQEMU【本来は仮想マシンを実現するためのソフト】を利用してエンディアンを変換【別のアーキテクチャのCPU用にバイナリの命令を変換するという意味】したり、開発段階で再コンパイルすることがこれに相当する。メモリを移植するとはシステムのAPIを参照してOSの管理体制に委ねることがこれに相当する。ファイルシステムを移植するとはコンパイル時に組み込まれる標準的な低レベルなライブラリがカーネルに対するトンネルを持っていることがこれに相当する。この一番システムの低レベルかつ根本のところで移植するのが最も簡便で互換性的な移植方法である。ズレが生じる場合は制限があるとは言え、繋がってさえいれば動くというのは移植や互換性におけるセオリーである。

XQuartzがインストールしてさえあれば、ほぼすべてのLinuxのGUIプログラムは移植なしでもコンパイルし直すだけでApple OS X上でも動作するだろう。（ただしMacPortsなどのパッケージマネージャで予め依存のあるパッケージをインストールした上で、MacPortsで入手したバージョンのソースコードをコンパイルしないとコンパイルは成功しないのが大抵である。MacPortsで入手したソースコードでないとバージョンにズレが生じコンパイル時にエラーを吐くだろう。）おそらくファイルシステムのトンネルに当たるようなことはコンパイル時に組み込まれる低レベルなUNIX系のライブラリが実現しているものと思われる。

オーディオサーバーのトンネルは現状のXQuartzは（XQuartz自体がグラフィックサーバーのトンネルであるということも含めて）実現していないかと思われるが、これを装備するとするならCoreAudio-Phononを使うのが最も簡便な手法だろう。Phononは既にApple OS X上で動作するので、CoreAudio-Phononのトンネルのための実装は既に実現されているとは言える。つまりこれをシステムにインストールしてそれをLinuxの音声プログラムが参照すれば良い。GStreamerなどの他のオーディオサーバーを使うアプリケーションの場合でも、PhononがLinuxでも様々なオーディオサーバーのフロントエンドとして使えることから、Phononをインターフェイスに用いればCoreAudioと間接的に繋ぐことは可能である。

システムに配置されるグラフィックサーバーは一つだけとは限らないし場合によっては複数あると考えるのが自然である。複数のグラフィックサーバーを組み合わせる手法は様々なプラットフォームで開発されたリソースを活用するために有用な手法と言える。Display SVG、Quartz、X Window System、QuickDraw、Display PostScript、DirectX【Windowsのグラフィックサーバーという意味で勝手に定義して意趣的に使っている用語】、NeWSなどを組み合わせられれば良い。

画面全体はデフォルトのグラフィックサーバーであるが、画面の一部であるルートレスに他のグラフィックサーバーを組み込めれば良い。普通に考えるならデスクトップの領域を枠内に表示できれば良いが、メインに使うのはデフォルトのグラフィックサーバーとデスクトップ環境なので、サブのグラフィックサーバーはウィンドウマネージャ【ウィンドウを表示するコンポーネントという意味で意趣的に使っている用語】を通してウィンドウ内部に必要なエリア（大抵はアプリケーションウィンドウのフレーム内容）を描画するというのが実際的な利用方法だろう。追加で起動するグラフィックサーバーが一つでもウィンドウのエリア自体は複数あることも一般的に考えられる。

Phoenix Desktopでは環境全体でグラフィックサーバーの組み込みを用いるため、アプリケーションベースの機構はないし、プログラムがそのグラフィックサーバーを必要とした時に自動でそのグラフィックサーバーが起動してその領域を描画し、必要なくなれば自動終了するだろう。Mac OS XのXQuartzはアプリケーションベースでこれらの機能を扱って制御していることになる。