当然、中身のファイルを削除したり移動することも可能となりますが、パッケージ内容をエンドユーザが勝手に変更するのは非常に危険な事なので、この機能はオープンになっていない方が良さそうな気もするのですが？
さっそくProjectBuilderで自作アプリケーションをBuildするための準備に入ります。まずは「ViewJPEG_X」という名前の新規プロジェクトを作成し、自作アプリケーション用のソースファイル、ヘッダーファイル、リソースファイルを、そのプロジェクトフォルダ内へコピーします。
これらを、CodeWarrior IDEの場合と同様にプロジェクトリストに登録するわけですが、ドラッグ＆ドロップで全ソースファイルを一度に登録しようとしたら拒否されてしまいました（涙）。これを単独ファイルで行えば可能なのですが、効率が悪くてやってられません...。複数ファイルの一括登録には、Projectメニューの「Add Files...」を使う方法もあります。ただし、Navigationダイアログでフォルダごと登録すると、本当に「全部」フォルダ内のフォルダまで登録してくれます。下手をすると、後で不要なファイルを削除する手間の方が大きくなってしまいますので注意しましょう。これはドラッグ＆ドロップによるフォルダ登録でも同様です。確実な方法は、プロジェクトの「Source」グループを選択し、NavigationダイアログのCommandキー＋マウスクリックによる複数ファイル選択機能を使うことかもしれません。また、現状のProjectBuilderでは、先んじてリストに登録されているフィルも重ねて登録できてしまいますので注意してください。こちらは仕様というよりはバグでしょうね。
続いて、雛形として登録されていた未使用ファイル（main.hやmain.rなど)をプロジェクトリストから外します。Projectメニューを探しても「Remove Files...」という項目が見あたらないので、プロジェクトからの登録解除はEditメニューの「Delete」（もしくはdeleteキー）を使うようです。メニューから「Delete」を選ぶと以下のようなシートダイアログが表示されます。
メニュー項目は「Delete」なのに、タイトルには「Remove」と表示され、「Delete」と「Don’t Delete」というボタンがあります。つまり、リストからファイルを外し、なおかつそのファイルをハードディスクから削除するかどうかを聞いているわけです。最初のうち、私は深く考えずに「Delete」ボタンを押してソースァイル自体を消してしまっていました！だって「Delete」を選んだわけですから、普通「Don’t Delete」ボタンはクリックしないでしょうに（笑）う〜ん、実にまぎらわしいユーザインターフェースです。危険ですから、ファイルの解除と削除（削除は無くてもかまわない）は別機能に分離してもらいたいものです。
プロジェクトウィンドウが大きすぎて邪魔だと感じる人は、リスト部分だけを表示させるようにすれば落ち着いて作業ができるかもしれません（笑）。
各種テキストファイルをリストに登録したら、内容を編集するためのエディターをオープンしてみましょう。プロジェクトリストのファイル名をシングルクリックすれば同一ウィンドウ内に、ダブルクリックすれば別ウィンドウでテキストエディターが表示されます。この時、ファイル元来のタブ幅や改行文字が現状の設定と食い違っていると、テキスト表示がボロボロになることがあります。こうした場合には、テキスト編集に関する項目の初期設定を、Applicationメニュー（一番左側）の「 Preferences...」で変更する必要��あります。テキストエディターに関する項目は、Preferencesダイアログの「Editing」パネルにまとめられています。
例えば、ディフォルトの「Tab Width」は8文字となっていますので、これをCodeWarrior IDEで使用していた文字数（4文字など）に変更すれば、テキスト表示が正常に戻ります。
続いてリソースファイルをプロジェクトリストに登録します。登録の仕方はソースファイルと同じです。「Inside Mac OS X System Overview」を読むと、リソースはデータフォークに保存されることが前提条件のようです。しかし、ここで登録するリソースファイルは、ResEditやResorcererで編集したリソースファイル（リソースデータはリソースフォークに保存）でも問題ありません。なぜなら、ProjectBuilderのLinkerがアプリケーションをパッケージ化する時に、リソースをデータフォーク保存し直したファイルを作成してくれるからです。こうしたBuildに関する細かな設定は、プロジェクトウィンドウのTarget名（Targetタブをクリックすると表示される）をダブルクリックするとオープンする情報設定ダイアログで行います。今のところ、そのダイアログの「Built Settings」ダブの「Linker Settings」により、リソースをどこに付加するのかを選択ができるようです。
メニューから「Data fork of a separate.rsrc file」を選択しておけばOKなのですが、もう片方の「Resource fork of the executable」にすると、何故だかLink時にエラーが出てアプリが作成されません？
さて、この時点でBuildを実行してみると大量のリンクエラーが発生して慌てることになります。試行錯誤しながら調べてみると、いくつかのフレームワークをプロジェクトリストに加える必要があることが分かりました。今回のプロジェクトに必要なフレームワークは、最初からある「Carbon.Framework」に加えて、「QuickTime.framework」と「Print.framework」の2種類のようです。この2つを追加すれば、今回のアプリケーションで使用しているAPIはすべてカバーできるはずです。プロジェクトの「External Frameworks and Libraries」グループを選択し、Projectメニューから「Add Frameworks...」を選びます。この時オープンしたNavigationダイアログは、フレームワークが保存されているフォルダ（System/Library/Frameworks/）を一発で表示してくれます。ダイアログで追加したいフレームワークを選べば、その内容がフォルダごとプロジェクトリストに登録され、Buildに必要な最小限の準備は完了したことになります。
Mac OS X自体についても言えることなのですが、ProjectBuilderで作業をしていると、ちょっとした仕様ミス（と私は思う）のおかげで結構ストレスがたまります。ファイル登録時に複数ファイルのドラッグ＆ドロップが使えない事や、「Delete」機能の変なユーザインターフェースなどは、ほんの一例にすぎません。速度が遅くてモタつく点や、機能自体が実装されていない事に関しては「β版だから」と許せます。しかし、無いと不便な簡単な機能（実装するのにたいした時間や労力はいらないはず）が無かったり、間違った方向で実装されていたりすると、本当に疲れます。次回はアプリケーションのBuildと起動、それからジャイアントアイコン（笑）の実装につてお話したいと思います。
[小池邦人/オッティモ]