RE;COIL (リコイル)メンバーのarc@dmzによる日記
記事「このブログについて」参照。RSS配信中。
Adobe AIRとは、mixi日記で去年6月頃触れた（当ブログに転載済み）、Adobe Flashをデスクトップに持ってきて通常のプログラムとして動作させるための仕組み。
ただし、ランタイム、すなわち一種のインタプリタ上で動作するため、OSネイティブなプログラムのように、Windows APIにアクセスしたりDLLの関数を利用したりはできない。よって、マシン語レベルで実行しないと厳しい計算処理などには向かない。
この欠点を補うため、OSネイティブなプログラムとDLL以外の方法で連携することを考える。
物理的に同じコンピュータ内での連携を目指すので、ファイルの読み書きを通して同期することもできるが、何とも前時代的なので却下。タイミングを合わせるのも難しかろう。
AIRアプリに許された外部との通信はTCP/IPを用いたもののみ。それならば、OSネイティブなプログラムでローカルホストに適当なサーバを実装し、そこへAIRアプリからアクセスすればよい。
さて、プログラムの開発フェーズで、デザイナとプログラマを分離するために、複数のプログラミング言語を使うやり方は、これまでにもいくつか出てきている。
| Webアプリ | Mozilla系プログラム | WPF系プログラム |
|---|---|---|
| 文書の内容を構造化するためにHTML | プログラムの機能を実装するためにCあるいはC++など | プログラムの機能を実装するために.NET Framework 3.0、あるいはSilverlight |
| 見た目をデザインするためにCSS | インターフェースを定義するためにXUL | インターフェースを定義するためにXAML |
| それぞれを連携させるためにJavaScript | それぞれを連携させるためにJavaScript | プログラム本体のコンパイル時に連携、あるいはSilverlightならJavaScript |
しかしながら、どの場合をとっても、簡易にプログラムを作ろうとすればOSの機能が制限され、それをフルに活かすには最低でも三つの言語が必要だった。
Qtをはじめとするクロスプラットフォーム用の優秀なフレームワークを使えば、どんなOSでも動くソースコードを一つの言語で全てを記述できて処理も高速だが、デザインと機能を分離しづらく、ソースコードが読みにくくなりがちだし、実行ファイルのサイズが大きくなる。
今回のようにAdobe AIRとOSネイティブなプログラムを連携させる場合、ActionScript(≒JavaScript)と、CあるいはC++言語さえ知っていれば、インターフェース部分をAIRで設計し、それ以外の処理をOSネイティブなコードで実行できる。
また、OSの機能の一部がPOSIXで標準化されたりしているおかげで、インターフェース以外の大部分は各種OSで共通のソースコードを使える。この点でも、Adobe AIRにインターフェースを任せて内部処理をCあるいはC++で書くやり方は都合がいい。
なお、Webアプリの開発に使える言語のみを用いてデスクトップ用のアプリケーションを開発できる環境(gOS、AIR OS…？)がそのうち整うことが予想されるが、まだ先のことだろうし、それらがコンピュータに搭載される単一のOSとして浸透するかと言えば、極めて怪しい。デュアルブートあるいはバーチャルマシンとしての実装は、もしかすると普及するかもしれない。
以上の考えに基づき、連携の具体例の一つとして、とあるデスクトップエージェントの設計概要をここに公開する。
システムの核をなす処理を行うプロセスをC-カーネル、インターフェースとしてユーザとのやり取りを行うプロセスをC-シェルと呼び、カーネルとシェルの間は専用のプロトコル(STTP)で通信を行う。
カーネルとシェルは各々基本的には独立して動作するが、シェルはカーネルへのアクセスに失敗すると強制終了する。カーネルはシェルからのアクセスを待ち受けるほか、Web経由のSTTP通信にも応答するよう設計される。
それぞれ以下の概要で開発を進めることとする。
「伺か。」をはじめとするSSTPサーバ・クライアント群と考え方は似ているが、
で完全に趣を異にする。
この本質的な違いにより、
といったことが可能になる。
STTP(Streaming Text Transfer Protocol) については、
以上、三種のアニメーションを定義する Streaming Text for Animation (STA) の通信に使われる新しいプロトコルとして仕様化する。Webとの連携も鑑み、HTTPとある程度互換性を持った仕様を想定している。
様々なOSで動く同じ機能を持ったプログラムを作るとき、一番問題になるのがGUI─つまり見た目の部分の処理だ。計算などの機械的な処理は今や同じコードを書いてあとはコンパイラに任せれば済むことが多いが、GUIまわりの実装はOSによって全然違うので、そこはOSごとに別々のコードを書かないといけない。
確かに、Windows(xpではLuna, VistaではAero)とMacintosh(�召�Aqua),Linux(GNOMEやKDE)…ユーザインターフェースはOSの数以上に様々な種類がある。
しかし考えてみると、ボタンやウィンドウなど、各インターフェースには共通項も多い。プログラマにしてみれば負担が増えるのは嫌でも、ユーザから見ればインターフェースの差だけでプログラムの機能が利用できなくなるなんて、ちょっとおかしい。
そこで、プログラマの負担は増やさず、多くのインターフェースに対応するコードを書ける「GUIツールキット」の出番である。このようなツールキットを使ってひとつのコードが複数のプラットフォームで動く状態を、「クロスプラットフォーム」と言う。
有名なGUIツールキットにはGtk+2とQtの二種類がある。
| ツールキット名 | Gtk+2 (GIMP Toolkit +2) | Qt |
|---|---|---|
| 開発言語 | C | C++ |
| それぞれを利用した Linuxデスクトップ環境 | GNOME | KDE |
GUIツールキットは、基本的に開発言語のライブラリとして提供される。（Gtk+2は、他言語へのバインディングも複数用意されている。）必要なライブラリを#includeなどで読み込んでGUI用の関数を定義し、それらを呼び出して使う。
さて、何かをクロスプラットフォームにする、ということは、基本的には各プラットフォームの共通項、つまり積集合(ベン図で集合の重なった部分)の機能を実現する、ということだ。すると当然、各プラットフォームに依存するネイティブなコードを書いたときより、実現できる機能は制限される。
だから、ツールキットは各OSの持つ先進的な機能は利用できないことが多い。
そんなふうにある意味ツールキットを軽視していて、今作ろうとしているゲームに必要となる機能が用意されていることは、はなからあまり期待していなかったのだが、どうもQtはバージョン4.1あたりから不定形ウィンドウがらみのおいしい機能が採用されていて、Win32APIにおけるUpdateLayeredWindowをうまくラップしてるとすれば普通に使いものになりそうなことが判明。
もしかするとこれはゲーム作りにも十分使えるかもしれない、と思い、さらにいろいろ調べつつこの記事を書いている。
Qtは、すぐに使えるようバイナリ版が配布されており、Windows版gccの最小セットMinGWで使うことを想定してコンパイルしたものが用意されている。これをダウンロードしてインストールし、MinGWを使うためのシェル、MSYSあるいはMS-DOSプロンプトで実行ファイルの生成を試み、その後、Cygwinで同じことができるようにする。
なお、Cygwinから直接、最新のQtが使える環境を整えることは、現時点では無理っぽい。できたら教えてえろい人。
まず、コンピュータの管理、環境変数からPATHにQtのバイナリが格納されたディレクトリを追加する。例えばC:￥qt￥4.3.2￥bin;。こうして、MSYSやMS-DOSプロンプトからGNU Make用のMakefileを作成するプログラムqmakeなどが使えるようにする。
examples内に豊富にサンプルが用意されているので、適当なものを選んで、MSYSから、そのディレクトリでqmakeを実行。Makefileが三種類生成される。Makefile.Release, Makefile.Debug, それら二つを包含するMakefileである。
これらでmake（mingw32-make）すれば、例えばMakefile.releaseならreleaseフォルダに実行ファイルが生成され、きちんと実行できるようになっている。
ただ、MSYSに使い慣れていない人ならCygwinでQtを使いたいこともあるだろう。そこで、CygwinでQtが使えるようにしてみる。
まず、Cygwinで普通にプログラムをコンパイルしようとするとCygwinに依存する(あるDLLを実行に要する)バイナリを生成してしまう。-mno-cygwinオプションを指定すればMinGWと同等な機能を使えるが、Makefile中でいろいろ面倒が起きるので、Cygwin上でMinGWを使うように設定する。
どうすれば Cygwin 環境内で MinGW を使えますか?にあるように、環境変数PATHの先頭に/cygdrive/c/MinGW/binなどを挿入すればいい。具体的には、bashシェルを使っているなら、.bashrcでexport PATH=/cygdrive/c/MinGW/bin:$PATHという行を追加すれば、bash起動時に自動的に環境変数が調整される。
こうして、Cygwin上でgccを呼び出したとき、MinGWのgccが呼ばれるようになった。
そのままの状態でqmakeすると、QMAKESPEC conf fileの「/usr/lib/qt3/mkspecs/cygwin-g++￥qmake.conf」が読めないと言われてしまう。
qmakeは、オプションを指定しない場合、Qtのインストールディレクトリ内のmkspecsにあり、qmakeを呼び出したプラットフォームに適したconf fileを自動で読むようになっている。MSYSの場合はwin32-g++￥qmake.confが読まれている。
Cygwinだとプラットフォーム名がcygwin-g++になるので、自動での読み込みは期待できない。そこで、-specオプションを付けてqmakeすることを考える。これは、conf fileをこちらで指定してやるオプションだ。
ただ、ふつうにqmake -spec /cygdrive/c/Qt/4.3.2/mkspecs/win32-g++としてもうまくいかない。「/cygdrive/c/Qt/4.3.2/mkspecs/win32-g++￥qmake.conf」が読めないと言われる。
MSYS(MinGW)ではディレクトリの区切りが「￥」なのに対し、Cygwinは「/」である。Cygwinから指定された/区切りのパスに、MinGW用qmakeがqmake.confを補完し、エラーが起きるのだ。さらに、Cygwinでふつう「/cygdrive/c/」にマウントされるCドライブには、MSYSでは「c:￥￥」でアクセスする。
そこでqmake -spec c:￥￥Qt￥￥4.3.2￥￥mkspecs￥￥win32-g++というようにMSYS向けのオプションを指定してやると、うまくいく。
以降は.bashrcにalias qmake='qmake -spec c:￥￥Qt￥￥4.3.2￥￥mkspecs￥￥win32-g++'などという行を付与するなどして、qmakeに自動的にこのオプションを指定するようにすればいい。
ここまでの作業でふつうにMakefileが生成されるが、肝心のmakeで「複数のターゲットパターンです。中止」と言われてしまう。パッと見、Makefileの文法はおかしくはないのだが…
試しにMSYSのmake（例えば/cygdrive/msys/1.0/bin/make）を使うと、ふつうにうまくいく。
まさか…
arc@x32 / $ /cygdrive/c/msys/1.0/bin/make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Report bugs to <bug-make@gnu.org>.
arc@x32 / $ make -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
これはフリーソフトウェアです. 利用許諾についてはソースを
ご覧ください.
商業性や特定の目的への適合性の如何に関わらず, 無保証です.
This program built for i686-pc-cygwin
というわけで、GNU Makeのバージョンが新しすぎるとうまくいかないらしい。あと、mingw32-make（GNU Make 3.80）でもいけた。仕方ないのでalias omake='/cygdrive/c/msys/1.0/bin/make'を.bashrcに指定し、omakeを使うことにして解決した。おまけ？なんかかわいい。
ここまで数時間かけてQtをCygwinで使えるようにしたが、ネットはなんとも広大なもので、Eclipseという統合開発環境を使って簡単にQtのプログラムをコンパイルできるやりかたがとある人の日記に書いてあった。話が逸れるが、この、とある人、面白いレンダラを作っている。今、学科の実験でレンダラを実行できるCPUを設計しているので、ちょっと気を惹かれた。
もともと、Qtを使う程度の規模のプログラム開発なら、よほどCygwin環境に慣れている人でなければ統合開発環境を使ったほうが楽なのは自明。ふつうの人にはそちらの方法がお勧め。
ついでにVS2005でQtを使うための情報もリンクしておく。英語でOKなら原文がいい。
あとは公式のFAQが役立つかも。
MinGWからQtを使って作成したバイナリは、実行にMinGWのランタイムDLLが必要となってしまう。その依存関係を解決する方法を見かけたのでリンクしておく。
ここで./configureする際は、-specが使えないのでconf fileを自動で読めなければならず、けっきょくMSYSが必要になるようだ。Cygwinだとダメだし、MS-DOSプロンプトで試してもうまくいかなかった。
追補; …Intel Pen3 1.8GHz, メモリ1.5GBの環境で、./configure -static, mingw32-make sub-srcにかれこれ二時間近くかかってるんだけど…何これひどい。あ、終わった。Qt、ファイルの総量2GB超って、何というツールキット…。
最新の記事を全23件中7件目から計2件表示
© arc@dmz 2007