HMDT July, 2002

「Finder は 1 つのアプリケーションにすぎない」ってのは、スティーブ・ジョブスがここのところ繰り返し言っている言葉だよね。それが意味するところは、Finder がユーザプロセスで実行される 1 つのプロセスである、ということだけではない。

Classic な Mac においては、Finder は Apple が示すユーザインタフェースの 1 つの規範だったんだ。アプリケーションを作る際に、ユーザインタフェースに迷ったら、Finder の流儀に従うことが多かった。そういうアプリケーションは、「Finder 風のユーザインタフェース」を売りにすることができたし、またユーザもそれを好きだったんだよね。

さらに、Mac OS 8、9 の時代では「Finder との融合」っていうこともよく言われていたよね。これは OpenDoc のインタフェースあたりからきてるんだと思う。具体的にどういうことをするかっていうと、

っていうことかな。ドキュメントの一部を選択して Finder に D&D。それをまた別のアプリケーションに D&D。マウス 1 つで快適ナビゲーション！いや、こんなコピーはなかったと思うけど。

で、これってやってみれば分かるけど、結構問題が多い。まず、ファイルの量が増える。当たり前だ。ファイルの量が増えると、管理するのがめんどくさくなる。きれいに片付けようとして、フォルダを増やして階層を深くすると、どこにあるか分からなくなるし、アクセスが難しくなる。ということは D&D がやりにくくなる。

あと、Finder から D&D をするには、Finder でウィンドウを開いておかないといけない。そうすると、開かれているウィンドウの数が増える。ウィンドウの数が増えれば、それだけウィンドウ同士が重なることが多くなって、アクセスしにくくなる。

という感じで、増え続けるファイルとウィンドウによって、どんどん使い勝手は悪くなってしまうのだ。ユーザインタフェースが売りの Mac OS にとっては、致命的だ。じゃあ、どうする？ここから先はまた個人的な推測だけど、Apple は Finder との融合をやめたのだ。そもそも、ファイルシステムベースのユーザインタフェースがよくない。ファイルがどこにあるか、っていうことと、ユーザがアプリケーションでやりたいことは、別だ。ということで、ファイルブラウザである Finder を、ユーザインタフェースの入り口にすることをやめたのだ。

Finder ではない新しいインタフェースとは？Apple のエンジニアの模索は、iApplication に現れている。

Finder の仕事 - ファイルを探す

まずは、Classic の Finder を振り返ってみよう。Finder の仕事は？それはもちろん、「ファイルを探す」こと。最近のコンピュータは、（知ってると思うけど）階層型のファイルシステムを採用している。もちろん、Mac だって。その階層の迷路の中から、ファイルを探し出すのが Finder の目的だ。

では、目的のファイルをどうやって探し出す？おそらく、まず最初に使われるのは、「ファイルのパス」だ。たとえば、「Macintosh HD」の下の「ドキュメント」フォルダの下の「写真」フォルダの下の「飲み会写真.jpg」ファイル。っていう具合にね。コンピュータっぽい書き方をすれば、"Macintosh HD:ドキュメント:写真:飲み会写真.jpg" って感じ（Classic なんで、セパレータはコロン）。

これに加えて、Finder はファイルを探すために、いくつかの手助けをしてくれるんだ。その 1 つはアイコン。ファイルやフォルダに好きなアイコンを貼付けることができる。これによって、「Music」フォルダというかわりに「音符がついてるフォルダ」っていえるし、「001.jpg」のかわりに「猫の絵がついてるファイル」っていうこともできる。

（こっから先は、個人的な推測だけど、アイコンから意味を読み取るのは難しい。たとえば、「ジグソーパズルのピース」の絵から、「機能拡張」という意味を読み取るのは無茶だ。だけど、一度「ジグソーパズル＝機能拡張」という図式が出来上がってしまえば（これは比較的簡単）、たくさんのフォルダの中から「機能拡張」の文字を見つけるよりは、「ジグソーパズル」の絵を見つける方がはるかに容易だ。なぜなら、文字より絵の方が認識しやすいから。これがアイコンの利点。って思うんだけど、こういう考えって、理論として確立されてたりしないのか？）

あと、もう 1 つ Finder が付加する情報は、ウィンドウの中での位置情報だ。基本的にウィンドウは二次元でしょ（当たり前だね）。だから、ウィンドウの右上とか、左側のまん中とか、いう位置情報でファイルを覚えることもできるんだ（これは当たり前ではない。Windows とかだと、この情報がうまく保存されないんだよな。Finder の利点の 1 つ）。

だから、Classic の Finder では、次のようなファイルの探し方ができたんだ。

「まず右上のハードディスクをダブルクリックするでしょ。次に右上にあるフォルダを開いて。そうすると、猫がついてるフォルダがあるでしょ。そのフォルダの中のいちばん右下のファイル。それ。」

ファイルとフォルダの名前だけではなくて、アイコンと位置っていう情報を使ってファイルを特定できるんだ。これらが Finder でのファイル探しを容易にしてくれてたんだ。

（この項続く）

「Mac と言えば Finder！」むかしからの Mac ユーザなら、そう思っている人もいるはずだよね。たしかに Finder はよかったよねー。おれも大好きだった。フォルダを、カチカチっとダブルクリックすると、すぱっ、と小気味よいズーミングアニメーションとともに開く。それだけで気持ち良かった。

それに対して、Mac OS X の Finder は何よ、あれ。動作がすっとろい、っていうのもあるけど、気持ち悪いったらありゃしない。あの Classic な Finder が持っていた、爽快感はどこいった？、、、でも、使い続けていると、意外にカラムビューって便利じゃない？実は深い階層をもぐるには、楽なんだよね。最近は、アイコンビューもリストビューも使わないで、もっぱらカラムビューだよ、おれは。

こんな感じで、賛否両論というよりは否定的意見ばっかりの、Mac OS X Finder。果たして Finder はどこへいくのか？HMDT では、そのヒントを iApplication に見た。現在、Apple 製ソフトウェアの最先端を走る、iApplications を足掛かりに、Jaguar の発売を控えた今、ポスト Finder を探ってみるのだ！

（この項続く）

Mac OS X の CoreFoundation には、CFXML っていう API があるんだ。読んで分かる通り、XML をパースしてくれる API だ。はたして、どのくらい使い物なる API なのか？まずは、軽く遊んでみた。

上の図は、CFXML を使って、アプリケーションの Info.plist をパースして、NSOutlineView で表示したもの。ここまでは、すぐできた。しかし、もっとヘビーな使用に耐えられるかは未知数。

プログラムでやっていることは、CFXML の high-level API を使って、パースして CFXMLTreeRef をとりだすだけ。何かの参考になるなら、どうぞ。

ダウンロード

NSDocument と NSWindowController との間のやり取り、日本語ファイルのエンコードの自動判別とかが、トピックスだよ。

Cocoa1001、前回NSDocumentController を使ってすべてのファイルを開くのところで、ファイルタイプ付きのファイルをどうやって開けばいいか分からない、と書いたら、Yoshiki さんがいい方法を教えてくれました。ありがとうございます！

それによると、拡張子に "*"、ファイルタイプに "" を指定すれば、すべてのファイルに対応できるようになるんだ。ただし、これだとファイルタイプのみを指定したドキュメントタイプが隠されてしまう。なぜなら、たぶん、NSDocumentController は、拡張子を優先してドキュメントタイプを認識しているからなんだ。

で、どうする？強引な方法だけど、NSDocumentController を継承して、ドキュメントを作るときに、ドキュメントタイプをすげかえてみた。うーん、素敵。コードは Cocoa1001 の方を見てね。

これで、すべてのファイルに対応できる。これって、本来ならフレームワークの中で解決しておくべき問題だよね。このファイルタイプをめぐる混乱を、どうにかしてくれ、Apple。

紫色のなにかさんで知ったけど、QuickTime 6 の MPEG-2 add-on、が Apple Store で売っているって！？

うぉぉぉ、ほんとだ。なんでこれだけ別売なんだ、Pro にも含まれないのか、どこにも説明がなかったぞ、理由を教えてくれ Apple。MPEG-4 の取り扱いに対して、MPEG-2 は悲しいな。MPEG-2 なら企業が金を払う、と踏んだのか？

説明を読むと、PS (Program Stream) はサポートしてるけど、TS (Transport Stream) はサポートしてない。むぅ。でも MPEG-2 から MPEG-4 や DV にエンコードできる。おぉっ！Pro が必要だけど。PS で MPEG-2 を吐けるデバイスがあれば、つなぐことができるわけね。

Cocoa1001、NSDocument の話の続き。きょうは、ドキュメントタイプの定義の仕方と、それを使って、すべての種類のファイルを開くにはどうすればいい？っていう話だ。

これ、本文の方に書いてあるんだけど、NSDocumentController を使って、ファイルタイプが付いていて、拡張子をあらかじめ決めておいてないファイルの場合の開き方が、分かりませんでした。だれか、知ってたら教えて下さい。

QuickTime 6 出たけど、個人的には MPEG-2 サポートがドロップしたのが残念。HD stream を Chinema HD で見れたりしたら、楽しいのに。いや、Chinema HD 持ってないけどね。

インターネットでの配信は MPEG-4 になるだろうけど、衛星や地上波は MPEG-2。Web コンテンツ作成にコミットする Apple は MPEG-4 を押し進めるか。でも、digital hub 的には MPEG-2 サポートも大事だと思うよん。それとも、そっちは TV に任せるのか？

Cocoa1001、これから少し Doument-based Application の話をするよ、いまさらだけど。いままで苦手だったんだよ、NSDocument とかって。でも、どうにか話ができるくらいには理解できたきたんで、まとめておくよ。

久しぶりの Cocoa1001。昨日話した Property list を XML 形式で取り出す話だよ。NSDictionary のカテゴリとして実装してみた。

Property list ってあるじゃない。ほら、アプリケーションの情報を書いておいたりする Info.plist のやつとか。あれは、メモリに格納するときは NSDictionary で、ファイルに保存しておくときは XML 形式とか、NSDictionary の description の形で保存する。

で、XML 形式で保存しようとしたんだけど、Cocoa-Objective-C には API がないのか？Cocoa-Java にはあるんだよ。NSPropertyListSerialization ってやつ。これは XML 形式をサポートしてる。Objective-C の Cocoa ではみあたらないぞ？Apple の Serialization のドキュメントを見ても、「Java には XML のシリアライズがあるよ」って書いてあるだけだし。うーむ。

CoreFoundation の Property List Service を使うしかないのかな。Apple は新しいサービスは Cocoa じゃなくて、CoreFoundation の方に追加していく傾向があるな。そうすれば Cocoa と Carbon の両方から使えるけど、個人的には C を使うよりは Objective-C の方が気楽でいいんだけどなぁ。Carbon 使いの人は、Objective-C より C++ に決まってるじゃん、と思っているのだろうが。

Project Builder のプロジェクトファイルと、Interface Builder の nib ファイルをのぞく PB IB Viewer、0.2 にバージョンアップしたよ。

アプリケーションの本質とはあまりかかわりのない、マイナーバージョンアップだ。

PB IB Viewer で、「nib の objects がのぞけないよー」って書いたら、ふたたびしましまさんから、「NSUnarchive で unarchive すればいいですよ」と、おそわりました。たびたび thnaks。で、unarchive したら、でてきたクラスは NSIBObjectData。

、、、えーっと、どうすればいいのかな。ヘッダに定義は見つからないし。メソッドの解析から始めますか。

先日、「Project Builder のプロジェクトファイルはテキストじゃないからのぞけないじゃないか」って書いたら、しましまさんからメールをいただきました。Thanks! 曰く、「プロジェクトファイルはパッケージですよ」。が～ん、そうだったのか。

ちなみに、教えてくれた、しましまさんのホームページはこちらの「みるく Cocoa」。Cocoa-Java のサンプルが豊富なサイトです。

で、話戻って、早速のぞいてみた。そしたらパッケージでした。その中にあるファイルは、テキストの property list 形式。これなら簡単に見れるじゃん。ってなわけで、ちゃっちゃとアプリを作ってみたよ。その名は、単純に「PB IB Viewer」。

Project Builder のプロジェクトファイル（.pbproj ファイル）と、Interface Builder の nib ファイル（こいつもパッケージだった）の中身を表示するアプリだ。ファイルメニューの「Open...」で .pbproj か .nib を指定すれば、中身がのぞけるぜ。でも、のぞいてもあんまりよく分からない、、、

あと、nib ファイルものぞけるんだけど、nib で一番興味があるのは、配置された GUI オブジェクトだよね？だけど、そのファイルはバイナリみたいで、property list 形式ではのぞくことはできなかった。残念。

Cocoa-Java でドキュメントベースのプログラミングしてたんですよ。でも、なんか期待通りに動かない。いくつかの機能の挙動が変。

具体的には、NSDocument を継承したクラスをパッケージ付きのクラスにしてたんだけど、それだと何か変。パッケージを外したとたん、動くようになった。パッケージ付きだと、いくつかの場面ではだいじょうぶだけど、まだ完全ではないような気がする。そんなことない？

こんばんは。mkino です。あー、いまお酒飲んで酔っぱらってます。

ここ数日、Cocoa-Java のプログラミングしてたんですよ。でもなんか、トラブル続きでとほほなんですけど。

たとえば、Project Builder って、ファイル名を直接変えれるじゃないですか。Files タブの中で。それで名前変えたら、コンパイルのとき、「（変更前のファイル名）が見つからないよー」とかいうんですよ。そりゃ見つからないよ、名前変えたんだから。まぁ、そこまでは百歩譲ってよしとしてやろう。だけど、そっから回復する手段がないじゃん。「プロジェクトのリフレッシュ」とか、そんな感じのメニューないの？いや、確かにかっこ悪いと思うよ、リフレッシュは。「最新の情報に更新」とかいう、どっかの Windows みたいだし。100% バグがなかったら、それでもいいんだけど、だめじゃん、実際には。しょうがないからプロジェクトファイル作り直しましたよ。

そうそう、あと、プロジェクトファイルがいまさらバイナリってのもないじゃない。隠さなきゃいけない情報があるならまだしも、ただのメイク情報でしょ？見せてくれ、頼むよ、ほんと。できれば Makefile は別に書き出してくれよ。その、GUI ですべてをラップする、っていう方針は、おれは好きなんだけど。100% バグがなかったら、それでもいいんだよ。でも、動かないじゃん、実際。

あとなんか、四六時中「Indexing...」やっているとか、ターゲットの編集が反映されるタイミングがいまだによく分かんないとか、複数ウィンドウで同じソースコードを出しているととたんに反応が重くなるとか、文句いっぱい。あと、個人的にはやっぱりタイリングウィンドウより、オーバーラップウィンドウの方が好き。あぁ、Code Warriror が懐かしい。Interface Builder もいいんだけど、オブジェクトの階層リスト表示がないのがおしい。Constructor のいいところをもっと取り込んでくれ。

Technote 2050 が公開されてるぜ！この Technote には、他のプロセスの開始と終了を調べる方法が書いてあるんだ。ただしポーリングはしないでね。つまりなんらかの通知を受ける方法だ。

いくつか方法があって、Carbon なら Carbon Event を。Cocoa か Cocoa-Java なら NSWorkspace を。UNIX なら Mach port を使うんだ。詳しくは Technote を見てね。サンプルコード充実。

で、個人的にきになったのは、Cocoa の NSWorkspace の記述に書いてあった注意事項。

と、いうことだそうな。だから、Cocoa からすべてのアプリケーションの終了を見たい場合は、Carbon か、Core Foundation を使って Mach port を監視すべし。