Snow Leopardでクリエータが無視される件、どうしようか。
10.6からは書類の識別にもUTIが本格導入されました。拡張子はそのUTIを決定するための判断材料として使われ、クリエータは無視されるようになりました。なので、テキストなどの一般的な書類の場合、クリエータやタイプをちゃんと指定していても、書類のダブルクリックで作成したアプリでないもので開かれてしまうということが起きます。また、この場合にはアイコンにもクリエータが反映されません。
こういった状況に対してユーザ側でとれるのは「Finderから開くアプリケーションを指定する」ことだけです。
プログラムを作る段階で独自のUTIを宣言しておいたらうまくいきそうですが、独自の書類でない限り、これは勧められません。テキストやJpegなどよくあるたぐいの書類はAppleの方で宣言していて、「プログラムと書類を結びつけるためだけに独自のUTIを宣言する」のは流儀に反します。さらに、あるUTIはより一般的な別のUTIの「子供」となるような階層を成し、独自のUTIはその継承関係も宣言する必要があります。テキストエディタのように「何でも書ける」アプリケーションでは、このあたりまできっちりやるのは少し荷が重いですね。独自のtxt、独自のhtml、独自のpl、独自のphp … とても全部は宣言しきれないです。
これらに理由により、CotEditorでは独自UTIを使うのは見送るべきだと考えます。
となると、「書類を保存するときに、ユーザがFinderで指定したときの情報を埋め込む」のが最良の策のように思えます。しかしここにも落とし穴があります。「ユーザがFinderで指定したときの情報」の情報は、リソースフォークなんですよ。しかもアプリのフルパスをそのまま埋め込んでいるというがっかり具合なんです。アプリ側で実装できないこともないでしょうが、ちょっとその気になれません。 何年もかけてやっと依存をなくしたと思ったリソースフォークをこういうところでこういう形で使うってのは、OSの仕様として間違ってると思うんです。なにか深い企みが隠されてるんでしょうか。
これらは、ターミナル.appで xattr -l ＜file path＞ とすれば、確認できます。
リソースフォークは便利といえば便利なのですが、ほかのプラットフォームに存在しないので互換性の面でいろいろ問題がありました。だからずっとなくす方向で来てると思ってて、AppleScriptだとかクリッピングファイルなどの一部に残っててもこれは代替えが効かないからかなとか想像してたんですけどねぇ。あと、そもそもの「ユーザがFinderで指定したときの情報」がリソースだっては以前のMac OS Xのときもそうだった訳ですが、「アプリのパスを埋め込むだけ」ってあまりにも暫定な対処だったんで、そのうちすばらしい解決手段が提示されるだろうと思ってたんです。まさかそれがそのまま正規の対処方法となってしまうとはなー…。
もしかしたらほかにも解決方法があるのかもしれませんが、調べた限りはこんなところです。
Comment
No Comments
（現在、コメントは受け付けていません。）