● 小池邦人のMac OS Xへの道 2001/04/06
〜 Navigation Serviceと拡張子の問題点 〜
今回は、Carbonアプリケーションの開発現場から見た「Mac OS X v10.0」の問題点を指摘してみたいと思います。NibベースのCarbonアプリの解説は、ProjectBuilderのパブリックβ版からの変更点を見極めてから再開する予定です。ご了承ください。
私が利用しているMetrowerks CodeWarriorは、すでにCarbon化されていますので、Mac OS X上でNativeアプリとして起動できます。ただし、パブリックβ版以前のMac OS Xをリファレンスに開発されていることから、製品版に対する最適化がなされておらず、エディターでの文字入力が非常に遅いといった弊害も目立ちます。風の便りに聞くところによると、Mac OS X正式版をレファレンスに最適化されたCodeWarrior IDE （もしくはアップデータが）が、5月のWWDCごろまでには配布されるのではないかという噂もあります。片やProjectBuilderの方は、β版と比較すれば随分と良くなったのですが、いかんせんコンパイルスピードが遅いのがネックです。現状、Mach-OベースのCarbonアプリを開発するのなら、とりあえずCodeWarrior環境できっちりとソースコードを開発し、それをProjectBuilderに渡して再度メイクするといった手段が一番かもしれません。
さっそく自作のCarbonアプリをMac OS X上で動かしてみたところ、いくつかの問題点に遭遇しました。CarbonLibは未だ発展途上なので、バグを含めて多くの不都合があるのは認識していますが、Mac OS X 環境自身に原因が起因する問題点も多いようです。自作アプリでファイルの保存をしようとしたところ、先んじて入力されているファイル名を（例えば「名称未定義」など）deleteキーで消さないとキー入力できない現象に遭遇しました。
それを一度削除してしまえば、その後はちゃんと日本語入力ができます。加えて、ファイル保存が正常に終了しない場合もあるようです。Carbonアプリでファイル保存を行うには、Navigation ServiceのNavPutFile()を呼びます。ソースコードレベルで調べてみると、ファイル名を入力したにもかかわらず、それがFSSpec構造体のnameメンバー（ファイル名）に反映されず、NULLストリングス（ゼロ）が返えって来ているのが原因でした。NavPutFile()からファイル名が得られないわけですからファイル保存は正常に行えません（涙）。これは自作アプリだけの現象でなく、AppleWorks 6でも同様に起こりました。AppleWorks 6でこの現象が起こると、アプリケーション自体が異常終了してしまいます（当然だと思う）。
さらに詳しく調べてみると、NavPutFile()のダイアログが表示された時点で英語スクリプト（英語入力モード）が選択されていると、日本語ファイル名を入力しても、それがFSSpecに反映されないことが分かりました。よって日本語スクリプトに切り替えてから入力すれば、問題なく日本語ファイル名は入ります。しかし、ダイアログを抜ける前に英語スクリプトに戻してしまうと、やはりFSSpecにはファイル名が代入されていません。とりあえず、NavPutFile()を呼ぶ前にKeyScript( smKeySysScript )を実行し、強制的に日本語スクリプトに切り替えておけば事故の確率は下がります。とは言っても、ユーザがダイアログを抜ける前に英語スクリプトに切り替えてしまえば元の木阿弥です。多分Navigation Serviceのバグでしょうが、改善されるまで待てませんので、ファイル名が入っていなかったら再入力を促す処理を追加することにしました。
次は、ファイルオープン時に使うNavGetFile()についての問題点です。昔々、ファイル選択ダイアログでプレビュー表示をさせたい場合には、StandardGetFilePreview()というAPI（CarbonLibでは利用できない）を使っていました。このAPIは、選択ファイルがQuickTimeでインポートできる画像、映像、サウンドなら、特別な処理をしなくても自動でプレビューを表示してくれました。ところが、Carbon環境で使用が義務付けられているNavGetFile()は、画像ファイルにプレビューリソース（'pnot'リソース）とサムネイルデータが付加されていないとプレビュー表示ができません。Navigation Serviceのドキュメントにはちゃんと「できる」と記載されているにもかかわらずです。ただし、この制限はMac OS 9上だけであり、Mac OS XのNavGetFile()では、ちゃんとQuickTimeインポートにによるプレビュー表示が復活しています。
「やれ嬉や！」と喜んだのもつかの間..。NavGetFile()のダイアログで画像ファイル名をダブルクリックしてもプレビュー表示が優先され、ファイル選択が認識されない現象が起こります。この現象は、プレビュー表示に時間がかかる場合（大サイズの画像ファイル）に起こるようです。ユーザとしては、プレビューなど見る必要がなく、ダブルクリックで即座にファイルをオープンしたい時があります。現状では、プレビュー表示がファイル選択の操作性を悪くしてしまうケースがあるようです。こちらはソースレベルで解消できる問題ではないので、クリックによるプレビュー表示よりもダブルクリックによるファイル選択を優先するように、Appleに変更してもらうしかありません。また、NavGetFile()が表示するリストに、同じフォルダが二つ表示されるという問題点も見つけました。以下の例では「Users」フォルダが二つ存在してしまっています。
Navigation Serviceは、 ファイルオープンや保存と言った非常に重要な操作に関わるモジュールですので、Appleは最優先でバグフィックスを行うべきでしょう。
続いて、ファイル名の最後に付けられる「拡張子」の問題点についてです。Mac OS Xでも、保存ファイルにはファイルタイプとクリエータを付加することができます。そういう意味では、Mac OS 9環境からの大きな変更はありません。しかし、Mac OS Xに付属している「Grab」などのCocoaアプリケーションは、ファイルタイプやクリエータを持たないTIFFファイルを保存してしまいます。またマウントされたデジカメのスマートメディアやコンパクトフラッシュのJPEGファイルなども、ファイルタイプを持たないファイルとして認識されているようです。Mac OS 9では、File Exchangeがファイル名の拡張子を判別し、自動でファイルタイプを割り振ってくれていました。ところが、Mac OS Xではその仕組みがまだ存在しないわけです。これはバグなのか？未実装なのか？仕様なのか？当方では判断できませんが、おかげでCocoaアプリが保存したファイルをCarbonアプリでオープンする場合などに大きな不都合が生じています。
通常のCarbonアプリケーションは、ファイルタイプによりファイル種類を認識しており、拡張子の取り扱いはFile Exchangeに任せています。例えば、NavGetFile()では、表示したいファイルタイプを指示することで、好みのファイルだけを選択対象としてリストに表示できるわけです。ところが、Cocoaアプリが保存したTIFFやJPEGファイルにはファイルタイプがありません。よって実際はオープン可能なのに、リスト上ではハイライトとなり選択できないという状況が起きてしまいます。加えてCarbonアプリでは、ドラッグ＆ドロップでファイルを取り込めるかどうかの判断にも、ファイルタイプを利用している場合があります。こうした場合、ファイルタイプの無いファイルは、ドラッグ＆ドロップの対象外となってしまいます。このような状況を避けるのには、ファイルタイプがゼロの場合に限って、ファイル名の拡張子をチェックしてファイルの種類を判断する処理を追加する必要があります。ひょっとしたら、こうした面度な作業を代行してくれるAPIが、CarbonLibのどこかにお隠れになっているのでしょうか？
File Exchangeの代用機能（？）なのかどうか分かりませんが、ファイル情報ダイアログに「アプリケーション」という機能があります。これにより、ファイルのダブルクリックで起動するアプリケーションを別物に変更することができます。まずは、ファイルタイプとクリエータを持っているファイルについて調べてみました。
設定項目を「特定のアプリケーション」にし、メニューで別アプリを選択してやると、確かに変更後のアプリケーションが起動するようになります。しかしアイコン表示は変わりませんので、クリエータを書き換えたわけではなさそうです。次に両情報を持たないファイルについて調べてみました。
すると、前はハイライト表示だった一番下の「アプリケーション変更...」というボタンが有効になります。これでアプリを選べば、新規クリエータとファイルタイプが設定されアイコン表示が変わるのだろうと予想したのですが、どうも違うようです。何も変化がありません...。これは、いったいどういう機能なのでしょうか？謎であります。
Cocoaアプリケーションでファイルタイプとクリエータを設定するために、AppleはCocoa環境からCarbon APIを呼ぶ手法を公開しているようです。しかし、根本的な解決には、Cocoaにファイルタイプとクリエータを扱うためのAPIを用意し、ファイルへの両情報の設定を義務付ける必要があると思います。加えて、Mac OS 9並みのFile Exchangeの実装も早急に実現する必要があるでしょう。