ファイルを開いても保存に使ったアプリケーションが起動しない

Snow Leopardになってからファイルを開く挙動が替わっていませんか?

例えば、Jedit Xでテキストファイルを保存(拡張子.txt)、それをダブルクリックで開いた場合、テキストエディット.appが起動。

同様にDreamweaverでhtmlファイルを保存(拡張子.html)、開くとSafariが起動。

さらに、InDesignやIllustratorで書き出したPDF、Photoshopで保存またはWeb用に書き出したJPEGやPNG、GIFも開くと全てプレビュー.appが起動していまいます。

Snow Leopard以前は、それぞれ保存に使用したアプリケーションが起動していました。

この仕様?バグ?なのかわかりませんが、非常に使い勝手が悪くなり困っています。

投稿日 2009/09/04 16:48

返信
返信: 34

2009/09/06 20:36 kanekaka への返信

アプリケーション(特に純正アプリ)によっては,ただしくクリエータ情報を保持できることがあるので,この差が何なのかがよく分かりません。

UTIへの対応はややこしいらしく、対応が杜撰なアプリと、きちんとしたアプリがあるようです。


2005年に下記のフィードバックを行いました。今思えば、Tigerで導入されたUTIにJeditXが十分に対応できていなかったからかもしれません。

http://homepage.mac.com/nojiri/macosx/feedback41.html#ignocreat

2009/09/06 21:40 野尻隆裕 への返信

野尻隆裕 さんによる書き込み:


Mail.appの仕様を変更して、ファイル添付時にMac専用のファイル属性を削除するようにすれば

先のコメント時にはスッカリ失念していました。

現在でも、この仕様になっていますね。

ドラッグ&ドロップで添付するのではなく、ファイルメニューの「ファイルを添付」を選べば、「Windows対応の添付ファイルを送信」というチェックボックス付きのファイル選択シートが表示されます。


それはわかっています。ただ、ドラッグ&ドロップの添付方法だと、ファイルをデスクトップやアプリケーション上で確認しながら簡単に添付できます。ところが、ファイル添付のダイアログボックスだと目的のフォルダまでナビゲートしてゆき、そこでさらに目的のファイルを探しだすというのが結構手間が掛かり面倒です。さらに言えば、私が問題にしたのは、どうしたら「マック・ユーザーが Windows ユーザーに迷惑を掛けずにファイルを添付できるか」ではなく、「マック・ユーザーからマックバイナリ形式のファイルを受け取った Windows ユーザーがマックのことを調べもしないで大騒ぎする(=常に Windows 形式のファイルを受け取れるのが彼らの当然の権利だと信じて疑わない)」態度のことでした。(あと、Windows ユーザーは当然のように、Word や「一太郎」のファイルを添付してきますが、それもなぁ...。)


--------------------

Apple 17" MacBook Pro (Intel Core 2 Duo T7600/2.33 GHz/3 GB RAM/500 GB HDD)

Mac OS X 10.6 (Build 10A432) [Snow Leopard]

2009/09/07 19:38 ni_ki への返信

ni_ki さんによる書き込み:


こういち さんによる書き込み:


未だに「クリエータ」らしき物は存在します。

これは、私も確認いたしました。

もしもクリエータが廃止されたのなら拡張子によってすべて開くアプリケーションが統一されるはずです。しかし、ファイルの「情報を見る」でファイル毎にアプリケーションを指定できますので。

ファイルに固有のIDのようなものが、与えれているのではなかったでしょうか。それであれば、個別のファイル単位では、今後も可能だと思います。

先の書き込みでクリエータが廃止されたという表現は、適切でなかったようです。クリエータが廃止されたのではなくて、(OSXから)参照が廃止されたという意味で書き込みました。


クリエータを保存するのは、アプリケーション側だと思っているのですが、それを参照して開くアプリケーションを決定するのは、OSXなのではないでしょうか。


7575さんの情報と合わせて考えると,今でもクリエータを設定するのはアプリケーション側なのでしょうが,ファイルシステム側が変更されていて,最新のAPI(Cocoa?)ではアプリケーションから正しくクリエータを設定できる。古いAPI(Carbon?)では新しいファイルシステムのクリエータを設定できない(ように仕様変更した?)。


LeopardのMac内にあるファイルをAFPでSnowLeopardから参照すると,クリエータ情報が無いファイルのように見えることから,SnowLeopardのファイルシステムに大きな仕様変更があったのかと思うのですが,変更する必要性が見いだせません(嫌がらせとしか思えない)。

合理的な理由はあるのでしょうか。

2009/09/13 02:56 7575 への返信

7575 さんによる書き込み:


アメリカのデベロッパーがこの件に気がつき、Appleに対して怒りのバグレポートを行ったら、

Appleから「意図した動きだ」という返事が来たそうです。


もしこれが事実だとしたら、バグではなく「仕様」だと言う事になりますね。


こういう記事が出ましたね:「Snow Leopard、クリエータコードにひじ鉄砲


--------------------

Apple 17" MacBook Pro (Intel Core 2 Duo T7600/2.33 GHz/3 GB RAM/500 GB HDD)

Mac OS X 10.6.1 (Build 10B504) [Snow Leopard]

2009/09/13 04:13 しい坊 への返信

記事を読みました。

記事に書かれているように、みんなでフィードバックを送るしかないでしょうね。

それも、数件のフィードバックでは駄目で、ここを読む皆さんからの怒濤のフィードバックでないと。

放置していれば、これが仕様として確定します。


@先にも書きましたが、クリエータ情報を無視するのが仕様としても、仕様に準拠しない動作もしているのですが。>Finder 10.6


P.S.

下記にフィードバックのテンプレートを用意しました。下記の内容をコピーしてご利用ください。

http://homepage.mac.com/nojiri/macosx/feedback61.html#creator1

2009/09/13 04:16 しい坊 への返信

しい坊 さんによる書き込み:


7575 さんによる書き込み:


アメリカのデベロッパーがこの件に気がつき、Appleに対して怒りのバグレポートを行ったら、

Appleから「意図した動きだ」という返事が来たそうです。


もしこれが事実だとしたら、バグではなく「仕様」だと言う事になりますね。


こういう記事が出ましたね:「Snow Leopard、クリエータコードにひじ鉄砲


リンク先が本当だとしたら,衝撃のニュースですね。

Leopard以前のOSとハードを温存して,当面は事態を見守ろうと思います。

このまま好転しなければ,悲しいことですが,Macとお別れの予感がしてしまいます。

新しいハードが必要になったらWindow7を使うことになるのかなぁ。。。

2009/09/13 04:53 野尻隆裕 への返信

野尻隆裕 さんによる書き込み:


当面は事態を見守ろうと思います。

それは、やめてください。

Appleの現状に不満があれば、何も言わないのではなく、声を届けてください。

何も言わない人は、相手にとっては「現状に満足している人」なのです。


新しいハードが必要になったらWindow7を使うことになるのかなぁ。。。

あちらも拡張子依存の点では同じですが?

まさか、クリエータコードの存在だけが理由でMacを?


投稿した後に野尻さんの記事を参考に早速フィードバックはしておきました。


Mac OSの魅力が相当高いことは認めますが,ソフトハウスの対応等を含めて,フィードバックの効果が現れなければ,将来的には最悪の事態も覚悟しないといけないかと,今回ばかりは実感しました。

2009/09/13 07:19 しい坊 への返信

こういう記事が出ましたね:「Snow Leopard、クリエータコードにひじ鉄砲


この記事を読む限り、Appleの

「クリエータは将来的に廃止されるので、今後アプリケーションを作る際はクリエータではなくUTIに対応せよ。」

とも読めます。


OSが対応しなくても、アプリケーションレベルで対応さえしてくれれば、ユーザレベルでは同じ環境といえるのでしょう。


でも、現状では対応しているアプリケーションが少なすぎます。。。

2009/09/13 07:29 こういち への返信

「クリエータは将来的に廃止されるので、今後アプリケーションを作る際はクリエータではなくUTIに対応せよ。」とも読めます。


私もそういうことなんだろうと思っていたのですが、そうなると先のリンクのこの文章が気になります。


ユーザーであるあなたは、Get Info (情報を見る) を使って特定のファイルに好きなアプリケーションをバインドさせることができるが、私の知る限り アプリケーション がその作業をする方法はない。おそらく、開発者の側がこの問題を回避するために UTI をうまく使うことはできるのかもしれないが、本当にそれが可能なのかどうか、可能だとすればどうやればいいのか、私には分からない。


これはApplication側で対応する術が用意されていないということなのでしょうか? 本当に?

だとすると大問題だと思うのですが、それを調べる術は私にはないので何とも・・・


でも、現状では対応しているアプリケーションが少なすぎます。。。


現状対応しているアプリケーションというのは何があるのでしょうか? あるのであれば、アプリケーション側での対応は可能ということになるかと思うのですが・・・

2009/09/13 08:23 HAL への返信

http://www.novemberkou.com/QuickLookPlug-in/preparation/exportUTI.html


私にはよくわからないのですが、こちらにアプリケーションの開発の仕方が書かれているようです。

実際に、Xcodeで新規プロジェクトをCocoa ApplicationでオプションCreate document-based applicationを選択して作成すると、option+comman+E で、上のページに出ているUTIの設定画面が出てきます。


おそらく、そうやって設定することは可能なのではないかと、、、


もしかすると、UTIをプロパティに設定してリビルドするだけで対応できるのかもしれません。

2009/09/13 17:06 こういち への返信

もしかすると、UTIをプロパティに設定してリビルドするだけで対応できるのかもしれません。

そのようですね。

UTIについて調べてみました。


http://wakabamac.blog95.fc2.com/blog-entry-887.html

http://www.itmedia.co.jp/enterprise/articles/0708/14/news005_2.html


様々なファイルシステムや様々なOSとの互換性を維持するには、クリエータコードよりもUTIのほうが優れているそうです。

さらに、4文字でアプリケーションを識別していたクリエータコードよりも、柔軟性があります。


Appleとしては、UTIはTigerで導入したのだから、対応のための時間ならもう十分にデベロッパーに与えていたということなのでしょう。

(対応アプリが身の回りに見あたらないのは、なぜだろう。やはりクリエータコードがある限り、それだけに対応していれば用は足りていたからなのだろうか。)


P.S.

UTIに関する良い解説があれば教えてください。いまいち理解できていません。(^^;


このメッセージは次により編集されています: 野尻隆裕

2009/09/14 00:01 野尻隆裕 への返信

わかばマークのMacの備忘録 : QuickFileType


こちらの説明を読むかぎりでは、今回一番の問題となるのはUTIというよりはusroリソースをアプリケーション側がいじれるかどうかにかかっている?


QuickFileTypeの作者さんのページにあるこの一言に全ては集約されているように思います。


-------------------------------------------------------

例えば、usro リソースにアプリケーションパスではなく bundle identifier と書き込むようになったとか。そして、アプリケーションから usro リソースをファイルに追加する API が公開されたとか。そういう仕組みが用意されているなら許す。でも、そんな情報は見つけられなかった。

-------------------------------------------------------


代わりの仕組みが用意されていたならばこんなに大騒ぎにはならないと素人ながらに思うのです。

# 百戦錬磨なデベロッパさん達が、そんな大事な情報を見落とすとも思えないし・・・


本当に代替の仕組みが用意されているのかなぁ・・・

2009/09/28 22:25 HAL への返信

アプリケーションの一例を、adobe社製品で考えてみると、基本的にファイルの扱いは上位バージョン互換ではありますが、実際にファイルを開くとなると多種多様です。クリエータ情報がファイルにあっても、後からインストールした別バージョンの同アプリケーションがあれば(同じパーティション内に2つのバージョンがあると、エラーの原因にもなりますが)、アプリケーションが起動していない状態でのファイルのダブルクリックでは、新しくインストールした方のバージョンが起動します。これはos8以降。

acrobatで言えば、acrobatで作成されたファイルでも、pdfファイルをweb用に最適化してファイルの開き方をファイルに指定しない場合、ファイルのダブルクリックでは、preview.appが起動します。これは、Mac OS X Panther v10.3 Adobe Creative Suite 1以降。

代替の仕組みが確立されているかは知りませんが、ご参考までに。

2009/09/04 17:25 Tec8 への返信

コメントありがとうございます。


その方法も一応理解しております。

ただ、同じ拡張子を持つファイルを開くためのアプリケーションを変更するだけで、

同じ拡張子でも、保存に使用したそれぞれアプリケーションを個別に開く対策にはならないのです。

Snow Leopard以前のシステムがクリエータ/ファイルタイプを参照していたようにはなりません。


これが仕様でなく、バグである事を願っています。

2009/09/04 17:51 7575 への返信

成る程、PhotoShopでjpegファイルを保存して確認してみたら、確かに10.6ではPreview.appでファイルが開かれますね。10.5.xまでは、PhotoShopで保存した物は、PhotoShopで開かれていましたよね。


私自身は、これで困ることはないのですが、困る方はいらっしゃるのは、理解できます。

このスレッドはシステム、またはAppleコミュニティチームによってロックされました。 問題解決の参考になる情報であれば、どの投稿にでも投票いただけます。またコミュニティで他の回答を検索することもできます。

ファイルを開いても保存に使ったアプリケーションが起動しない

Apple サポートコミュニティへようこそ
Apple ユーザ同士でお使いの製品について助け合うフォーラムです。Apple Account を使ってご参加ください。