「MacOSXの新着アプリテスト記録とトラブルシューティング」の10月6日記事を拝見していたら、Temperature Monitorが取り上げられていて、かつて愛用していたことを懐かしく思い出しました。現行バージョンは4.8ですが、HD内を探してみると保有していたのはバージョン3.1でした。
現在はX Resource Graphを使用してます。わたしの場合、CPUなどの温度表示ができれば十分だったんですね。今サイトを見てみたら、つい先日の10/5に新バージョンが公開されてました。
]]>昨日がサイト開設から丸11年目の記念日でした。12年目からは、新しいシステムとなります。
今後ともよろしくです。 :-)
「MacOSXの新着アプリテスト記録とトラブルシューティング」の10月6日記事を拝見していたら、Temperature Monitorが取り上げられていて、かつて愛用していたことを懐かしく思い出しました。現行バージョンは4.8ですが、HD内を探してみると保有していたのはバージョン3.1でした。
現在はX Resource Graphを使用してます。わたしの場合、CPUなどの温度表示ができれば十分だったんですね。今サイトを見てみたら、つい先日の10/5に新バージョンが公開されてました。
]]>
ここのところ、CotEditorのSnow Leopard対応についてずっと考えてます。特に、クリエータの件で。
Snow Leopard でクリエータコードが無視される件（その３）より。
クリエータコードが理解されていない状況を知ると、クリエータコードの無視という暴挙も正しい判断に思えてくる
クリエータコードの廃止は長い目で見れば必然であったので、それ自体はやむを得ないと思っていて、そういう意味では確かに「暴挙も正しい判断」かもしれません。問題は、対応策があまりにずさんだということです。いきなりクリエータが参照されなくなったときの混乱に想像が及んでいないこともそうですし、アプリのフルパスを書類のリソースへ格納って美しくないにもほどがあるというか…。せめてファイル拡張属性を使えばよかったのでは。
いろいろ考えてみたのですが、こうなった以上は開発側でできるのはアプリで書類を保存するときにusroリソース（Finderで開くアプリを指定したときに作られる）を同時に書き込むしかないってことですよね。わたしは一般に入手できるディベロッパ情報しかアクセスできない（うえにちゃんと読めてない…）のですが。CocoaにそのためのAPIがあればうれしいですけど、可能性は低そう。栗田さんのQuickFileTypeのようにNDResourceForkを使おうか…。
まずは、10.6での開発環境を整えないと。Snow Leopardにしてから、数回しかXcodeを起動してないし。
Snow Leopardに同梱されてるQuickTime Xのプレーヤーですが、wmvが開けるようになってますね。10.5ではサードパーティー製のflip4Macがないとダメだったんですが、アンインストールしても見れました。
そういえば、QTのプレーヤーは縦横の比率をちゃんと反映してくれないときがあって映像が横長になってしまったりしたときに、QT7ではShiftを押しながらウィンドウサイズを変更すると縦横の比率を無視して変更できたのに、新バージョンはできなくなってます。ほかのキーもいろいろ試してみたんですが、わかりません。
どうすればいいんだろう。 :-!
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のときもそうだった訳ですが、「アプリのパスを埋め込むだけ」ってあまりにも暫定な対処だったんで、そのうちすばらしい解決手段が提示されるだろうと思ってたんです。まさかそれがそのまま正規の対処方法となってしまうとはなー…。
もしかしたらほかにも解決方法があるのかもしれませんが、調べた限りはこんなところです。
アプリ起動時に「Where is XXX?」とアプリの場所を確認するダイアログが表示されることがある件ですが、SIMBL0.9.1bによるものだったと思われます。Safari Realizedさんの記事に、情報がありました。
SIMBL 0.9.1bをインストールすると、プレビュー.appやスティッキーズ、テキストエディット等OSに付属するアプリケーションを起動した際に"Choose Application"と言うウィンドウが表示されます。
SIMBL0.9.2bが出てますのでアップデートしたところ、出なくなりました。 :-) のですが、まだ出てました（涙）
追記：0.9.5bでは直ってました。
]]>
タイトル通りですが、10.5から上書きアップデートで10.6にしました。
実行前にTime Machineでバックアップをとっておきました。アップデート作業は途中の再起動を挟んでトータルで約１時間。思ったよりもかかりました。いくつか気づいたところを。
こんなところです。最後の「クリエータが無視される」件は拙作にも関わってくるのですが、対応含めいろいろと調査中です。
あと、アップデート作業そのものは上記の通りやや時間がかかったものの無事完了。しかし続けて行ったRosettaとディベロッパツールの追加インストール直後、あるアプリ（10.5時代にインストールしていたもので、今回の作業には無関係なはず）に付属しているAppleScriptインストーラが起動し、何度終了させてもまた再起動してくるという謎の状態に。OSごと再起動して、復旧しました。いったいなんだったんだろう。
その後は問題なく使えてます。
Up-to-Dateプログラムのブツはなかなか簡易な包装です。ぷちぷちが内面に貼付けられた封筒に、簡単な紹介書類とDVDのみ。シンプルだ。DVDの袋には「Not For Resale」とシールが貼ってあるし。
各所のインストールレポートをちらちら拝見してますが、上書きアップデートでも問題無さげですね。でもやっぱりインストールは週末になりそう。平日深夜に何かトラブるとどうしようもなくなるし。
10.6環境でのCotEditorの挙動を心配していたのですが「動いてる」という記事を読み安心しました … が、どこで拝見したのかわからなくなってしまいました。すいません＆テスト感謝。