にょろぷにらん

なぜ新たなRADツールか

2～3年前までは好んでC++ Builderを使っていたのだが最近Perlばかり使うようになってからInteractiveなGUIソフトを作っていなかった．ここに来てC++ Builderに戻るのではなく新たな道を探ろうとしたわけはいくつかある．
(1) 開発環境を無償ソフトでそろえたい
(2) マルチプラットフォームで動くものを作りたい
(3) C++ではなくスクリプト言語でサクサク作りたい
とか色々ある．

(1)が最大の理由で，特定の高価なソフトで作成した場合，どんなにスキルがある人でもそのソフトを持っていない限りそれを拡張したりメンテナンスしたり出来ない．フリーソフトなら見かけだけの物となるし，社内のツールでは最初に作った人の手から離れられなくなってしまう．

ここまでのアプローチ

まずはマルチプラットフォームで動く“wxWidgets”と無償のVisual C++ 2003ツールキットを使ってGUI環境をつくれないかと試す．wxWigetsについては半年ほど前にPerlで使えるwxPerlとVisualWxを試してみたが，VisualWxの完成度が低くて断念した経緯があり，まずはC++でと思う．

これに該当する物としてCode::Blocs，wxDev-Cppがあったが，wxDev-CppのVC対応版は完成度がいまいち．

しかし，Visual C++ 2003 Toolkitではシングルスレッドでしかデバッグビルドが出来ないので，やっぱりGCCで考え直す．GCCでと考えるとwxDev-CppがRADツールとして完成度が高い．

次にwxPythonのコードをはき出すBOA-Constructor(0.4.4)を発見．しかし完成度が低い．GUIならと考えてwxGladeを試すもこれまたいまいち．

wxWidgetsから離れてTkを使うSpecTcl，SpecPerlを試したがツールの使い勝手がいまいち．

さらに離れるが，Delphi互換開発環境のLazarusを発見．これはかなりDelphiに近いイメージ．問題はドキュメントが不完全なこと．しかし，Delphiのインターフェースをそのまま実装している感じであるのでDelphiがわかっていればおそらく使いやすい．

個別評価

Code::Blocks

IDEとしての完成度が高い．Dev-CppやVisual C++のプロジェクトファイルを読み込めるところが素晴らしい．コンパイルオプションも引き継がれるので最初のディレクトリ設定を正しく行えばコンパイルはすんなりできる．それとビジュアルが良い．

デバッグは上で書いたとおりシングルスレッドのものしか行えないが，Microsoft Debugging Toolを使って一応可能．ただ，Breakpoint, watchがDebug実行前に設定されていないと正しく反応しないようだ．

巨大なプロジェクトを読み込んで.cbp形式にて保存した後再度開こうとしたらクラッシュした．掲示板にプロジェクト処理は作り直し中なので安定していないとあったので，今後改善されるのだろう．

RADツールとしての評価は十分に出来ていないが，無償のC++用IDEとしては十分おすすめできる．ただ，Visual C++ 2005 Express Edition使えばいいと言われればそれまでかもしれない．

wxDev-Cpp(VC対応でない方)

Visual C++対応版でない方，すなわちmingw利用版はなかなかよさそう．C++を使うRADツールとしてはGoodな方であろう．GUIのパネル上にコンポーネントを配置していきなりBuildを行ってもきちんとGUIアプリケーションとして動作する．

ベースはwxWigetsベースのはずなのだが，用意されているGUI要素は妙にDelphiっぽい．プロパティページで設定した各種パラメータは実行可能なソースコードとして埋め込まれる．

生成されるバイナリが妙に大きい．stripしても3MBあった．

BOA-consrtructor

wxPythonで作られている，wxPython用RADツール．起動するとDelphiもどき画面が出る．見た感じは良い．

しかしGUI Buildとなると問題多発．

• FrameXX(XXは数字)という名前で作られるクラス名を変更する手段が用意されていない．ムリに変更してもIDEを再起動するまで反映されず


• 保存するまでGUIの変更がコードに反映されない．


• Sizerを画面上でどのように使えばいいのかよくわからない

他の人のレビューを探したらBOA Constructorはダメダメだと書いてあるものがあり，やっぱり時間の無駄だったとあきらめることにする．

SpecTcl

Tcl/Tk用のコードを出力するGUI Builder．Perl/Tk用も出力可能．
Tcl/Tkをインストールしておく必要がある．また，インストール時にバッチファイル中のパス編集が必要．

ホームディレクトリに設定ファイルを保存するように作られているのだが，Windowsではホームディレクトリのアクセスに失敗するケースがある．そうなると起動できない．その場合は環境変数PREF_FOLDERかSPECTCL_RCに保存先を設定しておくことで問題を回避できる．

アイコンが独特なので直感ではわかりづらい．加えて操作もわかりづらい．まずはサンプルを見て，何が出来るのかを良く観察しないと能力を低く見積もりすぎてしまう．

TkではPackerという物を使ってGUI要素を詰めていく．サンプルではそれを複数入れ子にして複雑な画面を作ったものが入っていたのだがその操作方法がなかなかわからなかった．あと，Undoが出来ないので間違ってクリックして余計なオブジェクトが置かれてしまった場合に消すのがやや面倒．

Perlのコードをはき出すとサブルーチンに生成コードが入ったファイルが出来る．本当に生成部分しか作られないので，それ以外のコードは自分で記述が必要．表示だけならサンプルコードを見れば簡単に真似できるレベルではあるが，目的はそこで入力されたものを使って何かをすることにあるわけで，その詳細についてはきちんとドキュメントを読む必要があるだろう．

姉妹ソフトとしてSpecTixというのがある．こちらはインストーラがついていて，Tclのバイナリも入っているのでより手軽に使える．TiXコンポーネントを使ったアプリケーションを動かすためには別途TiXが必要となるので，配布はあまり容易ではないかもしれない．(こちらは試していない)

追記:
Perl/Tkはcpanで配布されている物もActivePerlに入っている物もTk配下にTixのコンポーネントも取り込まれている．そこで，SpecTixを実行してみたのだが，何故かTixで追加されているはずのWidgetsを配置するボタンが左のバーに出てこない．

SpecTclで検索するとこっちも出てくるが，これは同名の全く異なるソフトのようだ．

Lazarus

Delphi/Kylixのデッドコピー．でも完成度は高い．
コンポーネントの互換性は完全ではないのでDelphiのコードがそのままコンパイルできるわけではない．

使い勝手は正にDelphiそのもの．コンパイル速度がDelphiより遅い(と言ってもC++よりは速い感じ)のは外部コマンドを使っているからか．
残念なことにドキュメントが不十分なので，Delphiを知らない人が使いこなすのは難しい．で，思いついた裏技がこれ．

Delphi 6 Personalは無償でダウンロードできる．これは個人利用専用で商用には使ってはいけないことになっている．もちろん個人でWindowsツールを作るならそのまま使えばよいのでそこで話は終了であるが，開発にLazarusを使う場合もVCLヘルプが役に立つと思われる．特に非ウィンドウ系クラスはこのマニュアルがないとさっぱりわからないであろう．

あと，生成されるバイナリが妙に大きい．初期状態でコンパイルしたら7MB．でもstripしたら1.6MBになったのでぎりぎり許せる範囲か．(許せるかどうかはソフトウェアの魅力によるだろう)

Delphiで覚えた知的資産がほぼそのまま生かせるというのはかなり大きい．新しいツール＝新しいクラスライブラリだと個々のコンポーネントの使い方を1から覚え直しになってしまう．倫理的にここまでコピーしていいのか？というのはあるが，実用性は高そうだ．

結局

こんな話を聞いたことがある．ある夫婦が車を買いたいと思い，いくつかのディーラーへ車を見に行った．するとどこへ行っても「この車はメルセデスのように...です」とメルセデスを引き合いに出してその長所を説明されたので，結局メルセデスを買うことに決めたという．

RADツールではどれも「Delphiのように...」と書かれていることが多い．ならDelphi買っておけば間違いない，というかDelphiと比べるとどれも見劣りする．

Delphiが他のGUI Builderツールと大きく違うのは，デザイン段階でもコンポーネントがデザインモードで実行されている点だ．Visual Studio等の通常のGUI設計ツールでは編集中のGUI表示をツールで行っているのでカスタムコンポーネントに対応できない．Delphiは設計時の動作を規定できるので，様々な見栄えのコンポーネントを設計時から具体的なイメージを見て編集できる．

あと，RADとはいえGUI以外の部分が無ければソフトとして価値がない．実際に使うにはクラスライブラリに習熟していないとダメだろう．特にDelphi以外ではRADだから使えるのではなく，RADでなくても使えるけど効率化のためにRADを使うレベルに達しないと使いこなすのは難しい．かといってそこまで達してしまうとカスタムコンポーネントがツールで扱えなかったりツールがコンポーネントを100%サポートできていなかったり，カスタムコンポーネントが扱えなかったりしてツールの制限が腹立たしく思えてくるだろう．

最近作られたUltimate++等を今回試さなかったのは，結局なんだかんだ言っても最初にやり方を覚え直さないといけない点，それと新しい物に付き物のドキュメントの不十分さと安定度に対する不安があったからだ．10年前のコンパイラを対象とした古いインターフェースと効率の悪さの点でwxWigetsを批判しているが，ドキュメント，周辺ツール，安定度等を考えれば10年の積み重ねはそれなりの重みがある．

効率が悪いと言っても効率の良さは自由度の低さの裏返しであることも多いし，C++の機能に頼りすぎていないからこそwxPython等他の言語のBindingが生まれたという側面もある．

結局，真のRADはDelphiで．それ以外ではGUIツールはサンプルコード生成ツールくらいにとらえた方が良いかも．(特にパラメータをコードに埋め込むタイプ)