カテゴリー : MacOS X,自作ソフト
このカテゴリーの登録数：7件 表示 : 1 - 7 / 7
Snow Leopardでクリエータが無視される件、どうしようか ＜その2＞
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のときもそうだった訳ですが、「アプリのパスを埋め込むだけ」ってあまりにも暫定な対処だったんで、そのうちすばらしい解決手段が提示されるだろうと思ってたんです。まさかそれがそのまま正規の対処方法となってしまうとはなー…。
もしかしたらほかにも解決方法があるのかもしれませんが、調べた限りはこんなところです。
Snow Leopard到着しました
帰宅したらポストに入ってました。予定より１日早かった。 
Up-to-Dateプログラムのブツはなかなか簡易な包装です。ぷちぷちが内面に貼付けられた封筒に、簡単な紹介書類とDVDのみ。シンプルだ。DVDの袋には「Not For Resale」とシールが貼ってあるし。
各所のインストールレポートをちらちら拝見してますが、上書きアップデートでも問題無さげですね。でもやっぱりインストールは週末になりそう。平日深夜に何かトラブるとどうしようもなくなるし。
10.6環境でのCotEditorの挙動を心配していたのですが「動いてる」という記事を読み安心しました … が、どこで拝見したのかわからなくなってしまいました。すいません＆テスト感謝。
とらとらとら、その後。
Tiger で LiTaG cocoa がうまく動作しない件、ドラッグアンドドロップでの変更もありつつデータ構造関連での変更が主因でうまくいかない模様。くはー。もう少し時間ください。
夢荘さんの記述を読んで、「Spotlight の検索フィールド表示」が Cmd + Space になってしまうのは、もしかしたらキーボードをみてるんじゃないかと思い当たりました。拙宅のも US キーボードです。キーボードよりもメイン言語をみた方がいいと思うけどどうなんだろ。Pafuxu さんからいただいたコメントのように、Ctrl + Space に変えました。
とらとらとら
Tiger、お昼ごろとどいたよー！
やっぱり住所が違ってたってことで配送業者から電話をもらって、目覚めたのでした。運ちゃんに「起こしちゃってごめんねー」とか言われたよ …。
ネットを見る間も無く、そして到着情報をアップする間も無くそそくさとインストール開始。まっさらなパーテーションを指定するのは気持ちいい。いつも通りのインストーラ、特に変わった様子なし。カスタマイズせず、標準のパッケージをインストール。
ぼけーっとインストール終了を待っていたんだけど、気付くと1時間近く経過していた。インストールが速くなったとか聞いてたんだけど、あまり変わらないような気もする。
OS のインストールが終了し例のオープニングムービーのあとで、従来の環境を移すかどうか聞かれる。他のパーテーションにある 10.3 からアプリやユーザなどを移すことにした。移行元のパーテーションを選択中になぜかまた冒頭のムービーに戻ってしまうという不穏な動きを見せて不安にさせてくれるおまけ付きだった。
しかし古い環境を移行させることで互換性の損なわれるソフトや設定も移されてしまうかもしれないわけで、ちょっと失敗したかもしれない。と、実行ボタンを押してから気付いた。
かなり時間がかかりそうなので、外に昼食をとりに出る。もう2時近かった。
戻ってきたら、ユーザ登録画面になってる。住所氏名などを入力して、アップルに送信されて、やっと Tiger 環境に。
一見あまり代わり映えしないけど、メニューバー右上の Spotlight アイコンや Dock の Dashboard などに虎らしさが。Mail.app のアイコンも微妙に変わってたり Finder で「ライブラリ」「サイト」など日本語で表示されてたり（バグだと言われてたけど、旧来のアルファベット表示の方が好きだ） しますね。あと、G5 のファンの音がややうるさくなってるのは、ずっと Spotlight の索引を作ってるからなのでしょうか。
それにしても、Cmd + スペース に「Spotlight の検索フィールド表示」が割り当てられてるのはいったいどういうことなんだろう。わたしの場合は旧環境を移したことでこんなふうになっちゃったのかもしれないけど、デフォルトでこうなっているのだったらとんでもない話だよなー。おまけに、IM の切り替え自体、イマイチうまくいかん …。
ということで、これから使い込みます。
ときに、ドラッグアンドドロップ関連で何かが変更されてるらしく、拙作の LiTaG cocoa が動きません。これから対策方法を調査します。しばらくお待ちください。
# 泣ける。
心配だなぁ、いろいろと。
いや、Tiger こと MacOS X 10.4 がまだベータ並みの質らしいってことじゃなくて、ま、それも心配だけどそのうち直るだろうし、この時期に出ることは予想より早くてユーザとしてはすっごくうれしいんですよ。でも、ソフトを書いてる立場からするとフクザツ。
まず、メインの環境にはすぐに入れられない。いまは HDD1台をまるごとメイン環境にして、増設 HDD をすべてバックアップにしてます。これを構成し直さないといけないでしょうね〜。10.4 のメイン環境と、10.3 の開発環境をつくって、それぞれバックアップをとるようにしないと。ここまでが面倒っぽい。
さらに、10.3 と 10.4 両方での動作確認があるし、10.4 での新機能をにらみつつ 10.3 で実装できるところまで頑張って、間隙を縫って（何のだ？）開発環境を 10.4 にしなければならん。動作保証できるバージョンと10.4+ のバージョンを切り分けてリリースして … とか考えてるとパニックだ。
… 実はそれも楽しいのだけど ＜ 完全におかしいです
そもそもなぜこの端境期に見事にぶつかってしまったのかというと、当初どこかで噂になっていた「Tiger は6月ごろ」というのをすっかり鵜呑みにしてしまったからなんです。その前には区切りが付けられるつもりだったんですが、あと2週間あまりではどうすればいいのかなー。
# ソースは忘れましたが、「Tiger はクリーンインストールでないとトラブるよ」とか読んだ気もするし、この機会にパーテーションを切ろうかな。
それにしても、楽しみです。
サウンドって...（2）
iCal のアラームが信用不能になっている (3) について。
なるほど iCal はサウンドと共にメッセージダイアログを出す指定
でしたか。それが出てこないのは確かに理由がわかりませんね。そのうちソフトウェアアップデートで修正される、に 10ガバス。
音声リソース読み込みについては、アプリを作るときに何か細工すれば（何かプロパティを設定する、とか）良かったような気もするのですが、いまだに XCode すらちゃんと触れてない状況ですので薮の中です。実は拙作の AHL-Runner でも似たような問題があって、早く修正しないといけないんですけど ...。
# それにしても「引用された自分の文章の中で誤字を見つける」のはなかなかハズカシイものですね（笑）
速攻で修正しておきました〜。
前回の記事の続きです。
ここのところ、CotEditorのSnow Leopard対応についてずっと考えてます。特に、クリエータの件で。
Snow Leopard でクリエータコードが無視される件（その３）より。
クリエータコードの廃止は長い目で見れば必然であったので、それ自体はやむを得ないと思っていて、そういう意味では確かに「暴挙も正しい判断」かもしれません。問題は、対応策があまりにずさんだということです。いきなりクリエータが参照されなくなったときの混乱に想像が及んでいないこともそうですし、アプリのフルパスを書類のリソースへ格納って美しくないにもほどがあるというか…。せめてファイル拡張属性を使えばよかったのでは。
いろいろ考えてみたのですが、こうなった以上は開発側でできるのはアプリで書類を保存するときにusroリソース（Finderで開くアプリを指定したときに作られる）を同時に書き込むしかないってことですよね。わたしは一般に入手できるディベロッパ情報しかアクセスできない（うえにちゃんと読めてない…）のですが。CocoaにそのためのAPIがあればうれしいですけど、可能性は低そう。栗田さんのQuickFileTypeのようにNDResourceForkを使おうか…。
まずは、10.6での開発環境を整えないと。Snow Leopardにしてから、数回しかXcodeを起動してないし。