TidBITS#1138/13-Aug-2012 TidBITS#1138/13-Aug-2012Mountain Lion 君臨する第三の週に突入した私たちは、この Apple の最新の大猫の、混乱を起こしつつあるいくつかの側面についてさらに深く掘り下げて検討する。Glenn Fleishman と Jeff Carlson は協力して、(Mountain Lion および iOS の) Messages アプリの Caller ID 機能を調べる。これを使って、返信がどのアカウントにあてて送られるかを制御できるからだ。次に、これもまたまさに同じような話題だが、Apple Mail がメッセージの作成または返信の際にどのアカウントを使用するかについて Joe Kissell が厳密な探究を試みる。最後に、Matt Neuburg は Mountain Lion における Modern Document Model (現代的書類モデル) に彼のレーザーのごとく鋭い視線を当てて、このモデルが Lion におけるモデルとどのように異なるのか、それがどんなに良くなっているのかを解説する。今週注目すべきソフトウェアリリースは Nisus Writer Pro 2.0.4 と Express 3.4.3、DEVONthink と DEVONnote 2.4、それに TextExpander 4.0.1 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Glenn Fleishman: [email protected], @glennf, Jeff Carlson: [email protected], @jeffcarlson
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
OS X 10.8 Mountain Lion の Messages (メッセージ) アプリは、私たちをとことん混乱させた。なぜなら、自分が送信したり受信したりする iMessage の個々のものが結局どこに出てくるのかがさっぱり分からないからだ。到着したメッセージが iPhone と、iPad と、複数の Mac に、すべて一斉に出現するのを見て、イライラした人たちもいる。そこに希望はない。なぜなら Apple はまだ、その時点ごとにあなたの目玉がどこに焦点を合わせているのかに応じてたった一台の受信デバイスを設定するようにはしてくれていないからだ。
でも、その反対の問題にもまた困惑させられる。もしもこれらの iMessage が、同じ Apple ID で登録されたすべてのデバイスに現われるようにできなかったとしたら、どうなるだろうか？ 私たちはこの問題に取り組み、この「機能」を有効にしたり無効にしたりできる方法を見つけた。そのための鍵となるのが "Caller ID" と呼ばれるものだ。この環境設定項目は、Mountain Lion または iOS の Messages アプリで、複数のアドレスが登録されている場合に現われる。（ただし iPhone においては、電話番号もまたアドレスとして扱われるので、たった一つの電子メールアドレスでもこのオプションが使える。）
Mountain Lion においては、Caller ID 設定は Messages > Preferences > Accounts にある。あなたの iMessage アカウントを選べば、複数のアドレスが登録されている場合、一番下に Caller ID メニューが出る。iOS においては、Settings > Messages > Receive At > Caller ID にある。
Caller ID は、iOS および Mountain Lion の Messages アプリが iMessage を別の人に送信する際に暗黙の "from" アドレスとして使うものを定義する。相手の人が返事をすれば、その人の返信はあなたの Caller ID アドレスにあてて送られる。そこまでは単純なことだ。けれども、あなたが個々の iOS デバイスや Mac に、それぞれ別々の電子メールアドレスのセットを割り当てている場合、事はややこしくなる。
例えば、Jeff が自分の MacBook Pro で、Mountain Lion の Messages アプリに [email protected]、[email protected]、[email protected] という三つのアドレスを割り当てていたとしよう。彼の iPhone では [email protected] のみ、彼の iPad では [email protected] のみであったとしよう。（これは仮想の話ではない。テストをする過程で、彼は自分がそれぞれのデバイスごとに異なる電子メールアドレスを割り当てていたことに気付いた。）
もしも Mountain Lion の Caller ID として [email protected] が選択してあれば、彼がテキストを Messages アプリを使って送信すれば、それに対する返信は彼の Mac のみに届く。もしも Jeff が Caller ID を変更して彼の [email protected] アドレスにすれば、返信は彼の Mac と iPhone に来る。もしも [email protected] に変更すれば、返信は Mac と iPad に来る。
さて、Glenn が Jeff に iMessage を送りたいとすると、これら三つの電子メールアドレスのいずれにも送ることができ、その文章は彼の Mountain Lion のチャットウィンドウには必ず登場する。けれども彼が返信する際、Mountain Lion の Messages アプリは常にその from アドレスを彼の Caller ID アドレスへと戻す。それに対して、もしも Glenn がさらに返信を送ってその際受取り人のアドレスを変更したりしなかったならば、彼の返信はその電子メールアドレスに対応したデバイスのみに届く。（Messages アプリの Messages ウィンドウの中で、会話の中の "To:" ラベルの右にある人の名前の上にマウスをかざしてから（その名前でなく）下向き矢印をクリックすると、メッセージの送り先となるアカウントを切り替えることができる。）
これにより、二つの可能性が提供される。
すべてのデバイスで同じ電子メールアドレス（のセット）を入力しておくことによって、または、すべてのデバイスで共通の一つの電子メールアドレスを Caller ID として選んでおくことによって、すべてのメッセージがすべてのデバイスに届くようにすることができる。現時点では、大多数の人たちにとってこのやり方が最も賢明な方法だろう。
デバイスごとの iMessage 用アカウントを設定して、それぞれのアカウントを特定のデバイスのための Caller ID sender と指定しておく。ちょっと不合理なやり方ではあるが、それでもこの方法によって到着したメッセージはすべてのデバイスで受け取ることができ、その後の返信は一つのデバイスのみに届くようにできる。例えば、Glenn はすべてのデバイスに [email protected] を設定しておけば、そのアドレスにあてた iMessage はすべてのデバイスで読める。けれども、彼の Mac の Caller ID アドレスを [email protected] に、彼の iPhone の Caller ID アドレスを [email protected] に設定しておけば、彼が iPhone で書いた返信への応答は彼の iPhone のみに届く。同様に、彼がどれかのデバイスで会話を始めれば、それを受け取った人はそれがどのデバイスから来たかなど気にせず、ただ返事を書けばよい。
もちろん、この第二のやり方は、まさに iMessage における一番のフラストレーションを浮き彫りにしている。もしも誰かが、このデバイスごとのアドレスを保存していて、あとで（Glenn の最新のメッセージに返信するのでも、彼の汎用の iMessage アドレスにあてるのでもなく）その保存したアドレスに新規のメッセージを送ったならば、そのメッセージは Glenn が現在使っていないデバイスにだけ届くことになるかもしれない！ また、iMessage 用アカウントに電話番号を使えるのは iPhone のみなので、誰か友だちが Glenn の電話番号にあてて、過去の iMessage 会話をすべて無視しつつテキストを送れば、その会話は彼の iPhone のみでしか読めないことになる。
そういうわけで、あなたが送り出すメッセージにどのアドレスが付くかに関してほんの少しだけの制御の手段はあるものの、他の人たちからあなたにあてて送られたメッセージが必ずあなたに届くようにする方法は、やはりたった一つのアドレスを自分のすべてのデバイスに割り当てておくことしかない。
こういったことすべてが、iMessage には足りないピースがあるという事実を裏付けている。どうやら Apple は、複数のアカウントに対する電子メールの集中型の管理方法を提供することを望んでいないらしく、それを個々のデバイスごとの管理に任せようとしているようだ。けれども Apple は、iMessage で用いられる電子メールアドレスを集中的に認証していて、Apple ID アドレス以外の個々のアドレスを一度にたった一つずつの Apple ID アカウントに対応させて確認している。どのメッセージがどこへ行くかについて、ほんの少しの援助が Apple から提供されさえすれば、たとえその際情報の管理のためにウェブサイトあるいは環境設定パネルが必要になったとしても、多くの混乱が取り除かれ、くだらない作業が要らなくなることだろう。
コメントリンク13186 この記事について | Tweet リンク13186
文： Joe Kissell: [email protected], @joekissell
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
"Take Control of Apple Mail in Mountain Lion" の発刊以来、何人かの人が Mountain Lion の Mail が送信メッセージで From アドレスを扱う方法に関する変更について尋ねてきた。最初私にはどう答えればよいのか分からなかった、何故ならば私の試験中にとりわけ驚くようなことには遭遇しなかったからであるが、更に多くの苦情が寄せられるにつれ (Apple のディスカッションフォーラムでの多くを含んで)、何かがおかしいことは明らかな様相を呈してきた。そこで私は調べてみることにした。その結果、Mountain Lion の Mail は送信メールを以前とは異なる取り扱いをすることが判明した。そしてユーザーの中には、Mail がメッセージをどのアカウントから送信するのか予見するのは腹立たしいほど難しいという経験をした人もいる。
Apple Mail は必要とする数だけのアカウントを幾らでも設定させてくれ、それぞれのアカウントが独自の送信メールサーバーを、或いはより多くの関連したメールアドレスを持つことを許される。新規メッセージを作成したり或いは既存のメッセージに返信したりする場合、Mail はデフォルトの From アカウントをあなたに代わって選択する。勿論そのメッセージのヘッダー部分のポップアップメニューから異なるアカウントを自分で選択することも出来る。これは全く妥当な話であり、私が思い出せる昔からずっとそうであった。
しかしながら、Mountain Lion で Apple は、送信メッセージに対して Mail が デフォルトの From アカウントを選定するルールを大幅に変えてしまった。その結果、個々の送信メッセージを注意深く (そして自分の手で) チェックしない限り、意図しないアカウントからメッセージを送信してしまうことも有り得る。これはとんでもない結果をもたらす可能性がある。例えば、仕事のメールを個人のアカウントから、逆もまた然り、送ってしまうことにもなりかねない。私は、Mountain Lion を使って最初の数週間ではこの現象に気付かなかった。その理由は私はいつも同じアカウントからメールを送るし、万が一異なるアドレスからメッセージを送ったとしても、どうと言うことにはならないからである。しかし多くのユーザーにとっては、この変更は重大事である。
では実際にはこの動作はどう変わったのであろうか？ 私が 100 をゆうに超える私が考えられる範囲の変数の組合せで実験した結果から、次の様なことが判明した。
Lion またはそれ以前では、動作は次の様である：
メッセージに 返信する 時、Mail は 常に そのメッセージが宛てられたアカウントから返信を送る。これは、あなたの設定やそのメッセージが何処に保存されているかには拘わらず真である。
新規メッセージを作成 する時、Mail は Composing 設定ペイン上の Send New Messages From ポップアップメニューで指定されたアカウントを使う (つまり、コマンドの言う通り)。デフォルト選択である Account of Selected Mailbox が意味する所は、Mail のサイドバーで現在選択されているメールボックス、それが何であれ、に付随したアカウントが送信メッセージに使われるべきものということである。しかしながら、もしローカル (On My Mac) メールボックスが選択されているならば、或いはもし選択されたメールボックスが全く無ければ、Mail は From アカウントをあるルールに基づいて選択するのだが、私は多くのテストを重ねたにも拘らずこれだというものには行き当たらなかった。そして、もしある メッセージ が選択されていると、それが何処にあるかに拘わらず、Mail はまた違う From アカウントを一目瞭然の理屈なしで選択する場合がある。
要は、Lion には Account of Selected Mailbox の設定に関しては多少の不確定さがあるが、その動作は大体予測通りである - そして返信に関して言えば、こちらは一貫性がありそして理屈に合っている。
一方、Mountain Lion で私が見たのは：
メッセージに 返信する 時：
サーバーベース (即ち IMAP や iCloud) メールボックスに保存されたメッセージに対しては、Mail はそのメールボックスに関連したアカウントを使う - そのメッセージが送られたアカウントやあなたの設定とは関係なしに。これはそれなりに意味を成すし、前とは違うということはあるが、殆どの場合同じ結果に収まるであろう。しかし...
ローカル (On My Mac) メールボックスに保存されたメッセージに対しては、もし Composing 設定ペイン上の Send New Messages From ポップアップメニューで Account of Selected Mailbox が選択されているならば (デフォルトの設定でもある)、Mail は... どうも... 勝手に選ばれた様に見えるアカウントを使う。Lion で新メッセージを作成する時の様に、私は何十ものテストを行い、パターンを見つけたと思う度に (例えば Accounts 設定ペインで有効となっている一番上のアカウント；iCloud が最初で次が Gmail；最後にメールを送出したアカウント、等々)、例外が見つかってしまった。私には皆目見当がつかない；私に言えることは Mail はどうもアカウント設定が変更されない限りは同じアカウントを一貫して選ぶように見える。しかし一方では、Send New Messages From ポップアップメニューで単一のアカウントが指定されていると、Mail はそのアカウントを使う - そのメッセージが宛てられたアカウントには関係なしに。(換言すれば、返信を新規メッセージの様に扱う。)
新規メッセージを作成 する時、Mail は Composing 設定ペイン上の Send New Messages From ポップアップメニューで指定されたアカウントを使う。Lion の場合と同様、Account of Selected Mailbox がデフォルトの選択であり、サーバーベースのメールボックスに対しても、同じ様に働くように見える。しかし、メールボックスが全く選択されていないか、或いはローカル (On My Mac) メールボックスが選択されていると、Mail は Inbox が最初に現れる (Mail のサイドバーの統合された Inbox で) アカウントを使う；このリストで Inbox を上下にドラッグすると順番を変えられる。
これが何故重大な問題になり得るのかを例証するには、三つの異なる POP アカウントを持っているユーザーを考えてみればよい - 個人用アカウント、仕事用アカウント、そして家族用アカウントの様な。これら全てのアカウントからのメッセージは色々なローカルメールボックスへとファイルされる、例えばルールに基づいて自動的に。これらのメッセージの一つに返信する時が来た場合には、ユーザーは、更に人手をかけることなしに、それを受けたのと同じアカウントから実際に返信が送られるということを信じることが出来るべきである。しかし、これまではそうであったが、今は必ずしもそうではない。従って、この返信メッセージは間違ったアカウントから来たという理由で見逃されたり捨てられたりするかもしれないし、メッセージが仕事用と個人用の間を渡り歩く結果となる、等々である。
私には、Apple がなぜこの変更をしたのか、意図的であったのかどうか、何故書いたものに載っていないのか、或いは将来元に戻されるのか、見当もつかない。この変更は意図的なものでありそしてあるしっかりした理由のために為されたのだが単に私には理解できない可能性もあるので、バグだと決めつけるには躊躇を覚える。いずれにしろ、この変更でユーザーは更なる思考と努力を払わねばならなくなった。そして全体として言えばこれは極めて悪い動きであると私には思える。もしあなたもそう思うのであれば、Mail > Provide Mail Feedback を選択してこの問題に関するあなたの思いを Apple に知らせてほしい。我々は Apple が OS X に対するアップデートでこれを変更してくれること願うことは出来る。
その間、申し訳ないが、私は Mail を Mountain Lion 以前の動作に戻すやり方があるとは認識していない。Account of Selected Mailbox ポップアップメニューから単一アカウントを選択することで Mail の動作を比較的一貫性のあるものにすることは可能だが、これではあなたのニーズに合わないかも知れない。同様に、サーバーベースのメールボックスだけを使用することが出来れば、この問題の一番重大な部分を避けることは可能である。これらの見るからに弱弱しい進言の他に、私に言えることはこの変更を認識しメッセージを送る時には注意を緩めないでということだけである。
最後にヒントを一つ、これは TidBITS Talk メーリングリスト上の Christopher Stone の好意によるものである：Mountain Lion で、現在作成中のメッセージの From アカウントを変えることにキーボードショートカットを割り当てることができる。この方がマウスやトラックパッドを使って From ポップアップメニューからアカウントを選択するよりは多少なりともやり易いかもしれない。キーボードショートカットを割り当てるためには、System Preferences の Keyboard ペインを開き、Keyboard Shortcuts をクリック、そして Application Shortcuts を選択する。+ (プラス) ボタンをクリック、そして Application ポップアップメニューから Mail を選択する。Menu Title フィールドで From ポップアップメニューに現れる通りに名前とメールアドレスをタイプする - 例を示すと：
Joe Kissell <[email protected]>
使いたいキーボードショートカットを入力しそして Add をクリックする；複数のアカウントのためには同じ手順を繰り返す。次回メッセージを作成時に From アカウントを変える必要があると分かったら、その対応するキーボードショートカットを押せばよい。
コメントリンク13189 この記事について | Tweet リンク13189
文： Matt Neuburg: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
最近リリースされた OS X 10.8 Mountain Lion において、Apple は（絶対にやらないだろうと私が思っていたことを）やってのけた。Apple は、後戻りをした... まあ、ある意味で。10.7 Lion におけるあるメジャーな機能に対するユーザーたちからの反発の声に耳を傾けて、それらの異論に応えるべく歩み寄ったのだ。Apple はその機能を取り去ることはしなかった。もちろん、そこまで願うのは無理な要求というものだろう。けれども Apple は、インターフェイスを変更し、ユーザーにより多くの選択肢とより広い可能性の範囲を提供してくれたのだった。
この記事では、その機能に関して Mountain Lion が Lion とはどう違っているかを大まかに述べるとともに、その結果として私が個人的に Lion よりも Mountain Lion をずっと好きになった理由を説明したいと思う。もっと詳しいことについて、またその他 Mountain Lion におけるたくさんのことについては、私の本 "Take Control of Using Mountain Lion" をご覧頂きたい。
Lion での状況は -- 問題となる機能は、Apple が Modern Document Model［訳者注： この記事では（便宜的に）この用語を「現代的書類モデル」と訳しておきます。］と呼ぶものだが、Lion で導入されたいくつかのテクノロジーを採用するよう適切に書き直されたアプリケーションによって書類が保存されたり処理されたりする方法だ。そのテクノロジーとは、次のようなものだ：
オートセーブ、これこそが現代的書類モデル (Modern Document Model) の核心となるテクノロジーだ。つまり、この機能に対応するアプリケーションによって開かれた書類は、あなたがそれを編集するに応じて自動的に自らを保存する。あなたは従来通りにその書類を明示的に保存することも できる けれども、少なくとも理論上は、あなたは現代的書類モデル対応のアプリケーションの中では明示的な保存操作を 一切 することなく書類に作業をすることが可能となる。ただし、最初だけは、おそらく、新規の名称未設定書類に対してその名前とフォルダ階層における保存場所を指定するためにあなたが保存操作をしなければならないだろうが。
Lion においては、書類ウィンドウの赤い「閉じる」ボタンの中に現われていた黒い点が、もっと前の Mac OS X システム以来ユーザーたちが長年慣れ親しんできたものであるのに、一切現われなくなった。書類が "dirty" (つまり保存を必要とする) 状態であることは、もはやない。なぜなら、書類は常時自動保存されているからだ。その上、これと同じ理由により、その書類が閉じられた際には「変更内容を保存しますか？」というダイアログが出ない。（ただし Lion でも例外的にこのダイアログが出るケースが一つだけあり、そのことについてはすぐ後で述べる。）書類が開かれたり明示的に保存されたりした後に変更を受けた場合はタイトルバーに Edited という単語が現われるようになったけれども、それだけでは十分に強力な合図とは言えないと感じるユーザーが多くいた。
再開 (Resume) はアプリケーションに関する機能で、アプリケーションが起動された際に、前回そのアプリケーションが走っていた際開いていたすべてのウィンドウ（特に書類のウィンドウ）が自動的に開き直されるというものだ。Lion ではこの挙動をグローバルにも、個々のアプリケーションを終了する際にも、切り替えることができる。（ただし、私が記事“Lion におけるゾンビ書類のミステリーが解決”(2012 年 5 月 23 日) で指摘したように、特定の状況下ではアプリケーションの起動時にそうしないようにあなたが設定していたとしてもウィンドウが再開してしまうことがある。）この再開機能はオートセーブ機能と緊密に統合されている。双方の機能が働いている場合、Mac OS X は明らかに iOS を模倣しようと試みている。iOS では、アプリに切り替えることと、いったん終了してから再び起動することとの間に区別がつかないのが理想だからだ。
Lion においては、現代的書類モデル対応のアプリケーションで新規の名称未設定書類がまだ開いている状態でそのアプリケーションを終了すれば、その書類が自動的に保存され（オートセーブ機能）その次にそのアプリケーションが走った際にその書類が自動的に開く（再開機能）が、これは再開に関するあなたの設定に関係なくそうなる。けれども、もしもあなたが新規の名称未設定書類を明示的に閉じれば（つまり File > Close を選ぶか、ウィンドウの「閉じる」ボタンをクリックするかすれば）「変更内容を保存しますか？」のダイアログが出て、その名称未設定書類を保存するか、あるいは不要なコンテンツをきっぱりと追放してしまうかのいずれかが選べる。
バージョン (Versions) は、自動保存される書類の現在の状態を記録しておいて、あなたがあとでその状態を取り戻すことができるようにするシステムの機能だ。それらの状態は、ある程度、自動的にシステムが管理する。その上、Lion においては、いったん書類が保存されれば（つまり新規の名称未設定書類でなくなれば）File > Save メニュー項目が File > Save a Version と変わる。もちろん、その書類は常時自動保存されているのだけれども、Save a Version を選べば、ただ単にそれが保存されるだけでなく、現在のその状態が Versions データベースの中に記録される。
Lion においては、Versions データベースへのアクセスは主として File > Revert Document メニュー項目を通じて行なわれる。ここから、Time Machine 風のインターフェイスでその書類のすべての保存された状態が示される。一つの特別な書類状態、つまりその書類が最後に開かれたり保存されたりした状態は、その書類のタイトルバーメニューからアクセスできることもある。
File > Save As メニュー項目は、System 6 (あるいはそれ以前) からずっとユーザーたちが慣れ親しんできたものだが、Lion には存在しない。新規の名称未設定書類の場合は、これは余分だ。なぜなら File > Save が同じことを、つまりその書類に当初の名前とフォルダ位置とを割り当てる機会をユーザーに提供するという働きをするからだ。既に保存済みの書類の場合は、その項目の機能は File > Duplicate 項目に置き換わった。こちらは、現在の書類の状態を、元の書類を閉じることなく、新規の名称未設定書類の中へとコピーする。その後で、ユーザーはこの新規の書類を保存する（つまり名前とフォルダ位置とを割り当てる）ことができる。
Lion での問題点とは -- Lion の現代的書類モデル (Modern Document Model) は、アプリケーションを通じてユーザーが書類に作業するやり方における革命を含んでいた。そして多くのユーザーにとって、それは自分たちが気に入る種類の革命ではなかった。いつでも自分の気持ちに応じて保存ができるという習慣を、アプリケーションがクラッシュするかもしれないからという理由で打ち捨てるのは、難しいことではなかった。けれども問題の核心は、偶発的な出来事に関係していた。
誰でも、書類に変更を加えたつもりが ない のに、アプリケーションを終了しようとして「変更内容を保存しますか？」のダイアログが出て驚いたという体験が一度はあるだろう。そんな場合、あなたは 実際 その書類に変更を加えていたのだけれども、それは誤って加えてしまったに過ぎない。おそらくそれは、あなたがコピーするつもりで誤ってカットしてしまったのかもしれないし、あるいは重要な内容の段落が選択されていた時にあなたの猫がキーボードの上を歩いたのかもしれない。そんな場合、このダイアログがあなたに警告をし、あなたを危機から救ってくれた。あなたはそのダイアログを見て、そのような意図しない変更をキャンセルすることができたからだ。ところが Lion の下では、そんなダイアログはないし、何の警告もない。意図せぬ変更もすべて、あなたの知らないうちに、ひょっとするとあなたの望みに反した状態で、自動的に保存されてしまう。
多くのユーザーたちが反対の声を挙げたのは、Lion のオートセーブ機能が、このような状況で落とし穴となってしまう可能性があるからだった。そもそもオートセーブ機能が防ぐようデザインされていたもの、つまり予期せぬデータ喪失が、まさにオートセーブ機能が原因となって起こり得るからだった。もちろん、Versions データベースがその書類のもっと早い時点の状態で使い物になるものを保存しているかもしれないので 本当の意味の データ喪失ではないかもしれないが、使い勝手の悪い Time Machine 風インターフェイスの中から望む状態のものを見つけ出すのは簡単なことではなかった。それに、もしもあなたが気付かぬうちに問題ある変更をそのまま保存してしまった後、その書類を閉じてそのまま何日間も、あるいは何週間も経ってから、それを開いてみて恐怖に震え上がり混乱に叩き込まれてしまったとしたらどうか？ Versions 機能は何が起こったのかをあなたが理解する助けになるだろうか？ その書類の望ましい状態は、はたしてデータベースの中にまだ含まれているだろうか？ こうしたことはすべて、あまりにも逆行したものに感じられる。まず初めに意図せぬ激烈な誤りをしてから、後になって（もしも幸運ならば）それを発見し、それを修正するためにジタバタと走り回るなんて！ その一方で、Lion よりも前は、そもそも正しくない書類を保存しようとした際に、誤りを犯す 前に あなたは警告を受けることができていた。
それからまた、実験という問題もある。誰でも、実験的に書類にいろいろな操作を意図的に施して、何か間違ったことが起こっても心配ない、なぜなら最後に保存することなく書類を閉じさえすれば害はないのだから、あるいはまた、Save As コマンドを使いさえすれば別の書類を生み出して未保存の変更点をそちらに残すこともできるのだから、と考えたことがあるだろう。ところが今や Lion では、あなたが実験的に施した変更を Lion が勝手に、あなたの背後で、あなたの意に反して保存してしまうようになった。もちろん、Lion は 本当の意味で 実験を阻もうとしている訳ではない。File > Duplicate を選びさえすれば、その書類の未保存のコピーで作業が始められるのだから、そちらでならば最後に保存することなく閉じるのは 可能 だ。しかしここでも、すべてが逆行しているように見える。なぜなら、実験を始める 前に、忘れずに File > Duplicate を選んでおかなければならないからだ。そもそも、それを忘れてしまうことは大いにあり得るし、施した変更が望ましいものではないということに、手遅れになるまで気付かないかもしれないのだから。
Mountain Lion が救いの手を差し伸べる -- この現代的書類モデル (Modern Document Model) 融合体の中に Mountain Lion がもたらしたのは、システム環境設定の General パネルの中の新しい二つのチェックボックスだ。これら二つのチェックボックスが、書類を閉じる際のアプリケーションの挙動に影響を及ぼすとともに、いくつかの新しいメニュー項目も生み出す。まずは、その二つのチェックボックスの説明から始めよう：
"Ask to keep changes when closing documents" (書類を閉じる際に変更内容を保存するか尋ねる。) もしもこのチェックボックスの チェックが外れていれば、Mountain Lion は Lion と同じ挙動をする。けれども、もしもこのチェックボックスが チェックされていれば、Mountain Lion はむしろ Snow Leopard やそれ以前と似た挙動をする。つまり、「閉じる」ボタンの "dirty" 黒点が復活する！ そして、"dirty" な（つまり保存を必要とする状態の) 書類を閉じようとすれば、警告ダイアログが現われる！ だから、Mountain Lion においては、あなたが書類への意図せぬ変更を誤って保存してしまう危険性が Lion ほど大きくない。
しかしながら注意すべきは、このチェックボックスがオートセーブ機能をオフにする訳では ない ということだ。あなたの書類は、依然として舞台裏で自動的に保存されている！ この警告ダイアログには "Do you want to save the changes...?" (変更内容を保存しますか？) と書かれていて、デフォルトのボタンには Save (保存) と書かれているけれども、実際にはその書類は 既に 保存されているので、ここであなたが実際に決断しようとしているのは、その保存された変更を そのまま受け入れる か、それともその書類の以前の状態（当然ながら Versions データベースの中に温存されている）に復帰するのか、という選択肢だ。つまり、オートセーブはまだ働き続けているけれども、このインターフェイスがまるでそうでないかのようなイリュージョンを与えている。
"Close windows when quitting an application" (アプリケーションを終了する際にウィンドウを閉じる。) この第二のチェックボックスはちょっと厄介で、これは実際には 二つの ことをする： (1) グローバルに再開 (Resume) 機能のオン・オフを規定するとともに、(2) 第一の チェックボックスに関する限り、アプリケーションを終了することがその書類を閉じることをも意味するかどうかを規定する。
どういう意味なのかを説明するために、まず最初にこの第二のチェックボックスの チェックが外れている 場合を考えてみよう。すると、開いた書類ウィンドウを持つアプリケーションをあなたが終了した際に、それらのウィンドウは何の警告ダイアログもなしにただそのまま消える。たとえ、それが "dirty" な書類のものであったとしても。ある意味で、このチェックボックスのチェックを外すことは、あなたが「アプリケーションを終了するのは書類ウィンドウを一つ一つ閉じることとは違うのだ、私が終了せよと言えば、それは今すぐ止めろということで、私はどんなダイアログにも邪魔されたくないのだ」と言っているのと同じことだ。このことは、たとえ第一のチェックボックス (「書類を閉じる際に変更内容を保存するか尋ねる」) がチェックされていたとしても当てはまる。なぜなら、この第二のチェックボックスによれば、アプリケーションを終了することは実際その書類を閉じることを意味しないからだ！ その代わりに、それらの書類の現在の状態が自動的に保存 (オートセーブ) され、そのアプリケーションが次に起動された際には自動的に (再開機能) それらの書類が開かれる。（注意すべきは、もしも第一のチェックボックスがチェックされていれば、それらの書類が自動的に再開された際に、それぞれの "dirty" 状態もその前のままに記憶されているということだ。もしもあなたがそのアプリケーションを終了した時点でその書類が "dirty" であったならば、再び開かれた際にもその「閉じる」ボタンには "dirty" 黒点が残っている。）
他方、もしもこの第二のチェックボックス (「アプリケーションを終了する際にウィンドウを閉じる」) が チェックされていれば、"dirty" な書類ウィンドウを持つアプリケーションをあなたが終了した際に、それらのウィンドウをどうするかは 第一の チェックボックス (書類を閉じる際に変更内容を保存するか尋ねる」) の支配下に置かれる。だから、もしも第一のチェックボックス も チェックされていれば、たった一つの "dirty" な書類ウィンドウを持つアプリケーションをあなたが終了した場合には「変更内容を保存しますか？」ダイアログが出るし、また複数の "dirty" な書類ウィンドウを持つアプリケーションをあなたが終了した場合には、お馴染みの Cocoa ダイアログが現われて、"You have ... documents with unconfirmed changes. Do you want to review these changes before quitting?" (変更内容を保存していない ... 個の書類があります。書類を閉じる前にこれらの変更内容を確認しますか？) と尋ねてくる。
さらに、もしもこの第二のチェックボックス (「アプリケーションを終了する際にウィンドウを閉じる」) がチェックされていれば、再開 (Resume) 機能がグローバルにオフとなる。けれども例えば終了の際にあなたが Option キーを押さえていれば、再開 (Resume) 機能が一時的にオンとなり、その場合は、あたかもこのチェックボックスのチェックが外れていたかのような挙動となる。つまり、あなたは「とにかく 今すぐ 終了しろ！」と言っていることになる。すると、そのアプリケーションは即座に終了し、たとえ 第一の チェックボックスがチェックされていたとしても、たとえ "dirty" な書類がいくつか開いていたとしても、それらに構うことはない。（そしてもちろん、次にあなたがそのアプリケーションを起動した際には、自動的にそれらのウィンドウが開かれ、"dirty" な状態も記憶されている。）
それに加えて、Mountain Lion の現代的書類モデル (Modern Document Model) では、次のようなメニュー項目が提供される：
File > Save は常時 File > Save であって、File > Save a Version に変わったりしない。当然ながら、以前に保存されたことのある書類を保存すればやはり一つのバージョンが保存 される けれども、メニュー項目名の変化がなくなったことで物事がすっきりした。
File > Duplicate メニュー項目は Lion と同様に存在しているが、それに加えて File > Save As メニュー項目も復活した。実際、後者は前者の代替となっている。（Option キーを押せば見えるようになる。）これにより、ユーザーが自分の使いやすい方、状況に適した方を選んで使えるようになった。前者つまり File > Duplicate は、現在の書類を新規の名称未設定書類の中へとコピーし、現在の書類のウィンドウは後ろにそのまま残す。一方 File > Save As は、Lion より前のシステムと同様、現在の書類のコピーを作って新たな名前と保存場所を与え、書類ウィンドウは元のものでなくその新たなコピーのウィンドウとなる。
File > Revert To は (Lion の File > Revert Document に代わるものとして) 今回から階層メニュー項目となる。そのサブ項目は、状況により異なるものの、Last Opened、Last Saved、Browse All Versions といった項目を含むことができ、最も普通の使用法に集中できるとともに、選択肢が分かりやすくなった。
最後に、これも非常に重要なものだが、Mountain Lion で完全に新しく設けられた二つのメニュー項目がある。File > Rename は、書類をそのまま直接改名する。File > Move To は、書類を別のフォルダに移動する。これらのアクションは、従来 Finder でファイルに対して実行していたものだ。今回から、その書類を開いているアプリケーションの中から直接、その書類に対してこれらのアクションを施すことができるようになった。これらのメニュー項目はいずれも非常に便利で、今までどうしてこれなしにやって来れたのかと不思議に思うくらいだ。
以上のメニュー項目はいずれも、File メニューの中だけでなく書類ウィンドウのタイトルバーメニューの中にもある。ただし奇妙なことに、Save As だけが例外だ。Save As のみが残念なことに二流の地位に追いやられ、必要以上に発見するのが困難になってしまっている。
（もう一つの変更についても触れておこう。Lion では、一定の期間、例えば二週間にわたって編集を受けなければ、その書類は自動的にロックされていた。Mountain Lion では、この自動ロック挙動が取り下げられた。もちろん今まで通りタイトルバーメニューから Lock を選べばその書類がロックされるけれども、これは Finder で書類をロックすることができるという昔からある機能と何ら変わりがない。）
結論は -- 私個人としては、これらの変更のお陰で Mountain Lion は Lion でそうでなかった部分においてはっきりと使えるものとなり、容認可能なものとなったと思う。おそらく、私と同じように感じているユーザーたちも多いのではないかと思う。私が特に強い印象を受けたのは、Apple がユーザーに選択肢を提供する姿勢を積極的に見せた点だ。それこそが、私が何度も Apple に求めてきたことなのだから。システム環境設定 General パネルの二つのチェックボックスのお陰で、ユーザーたちは Mountain Lion を Lion と同じように挙動させることも、また Lion より前の時代の書類の挙動を真似させることも、どちらでも自分がより安心し自信を持って使える方を選ぶことが可能になった。同じように、私は File > Duplicate と File > Save As の両方を、その時の作業の性質に応じて選んで使えるようになったことが嬉しい。それから私は、Apple が File メニューの項目を再調整してくれたこともありがたいと思う。特に、新設された Rename と Move To の二つの項目は、とにかく素晴らしい。
けれども、誤解して頂きたくないが、私は決してこの現代的書類モデルに完璧に満足している訳ではない。実際、正直に言ってしまえば、私の観点からは、オートセーブ機能はそれ自体極めて大きな過ちであって、デスクトップが iOS と同じようなものであるという、完全に誤った主張に過ぎない。その本質深くに内在する欠陥は、遠隔ディスクをマウントしてそこにあるファイルを編集しようとすれば馬脚を露わす。その状況においてはバージョン機能なしのオートセーブとなり、そこにトラブルがあることは Apple 自身でさえ認めている。この話題については Adam Engst の記事“ネットワークと非 HFS+ ボリュームで Lion の「バージョン」バグに注意”(2011 年 9 月 8 日) をご覧頂きたい。
また、Mountain Lion の中に "Documents in the Cloud" 機能が存在することで、さらなる複雑化要因が加わる。一部のアプリケーションの持つこの機能は、書類を iCloud が同期できる場所に保存する。この記事ではこれ以上深入りしたくないが、もしもそのアプリケーションが iCloud 対応ならば、現代的書類モデルのさまざまな警告ダイアログも、「開く」と「保存」のダイアログも、すべて iCloud 非対応のアプリケーションとは違ったものとなるとだけ言えば十分だろう。こうして、私たちは「デスクトップの三極バルカン化」とでも言うべき事態に行き着く。つまり、現代的書類モデルを用いないアプリケーション、現代的書類モデルを用いるけれど iCloud 対応ではないアプリケーション、それから現代的書類モデルを用い iCloud 対応であるアプリケーション、の三つだ。三者は三様に、それぞれ見た目も挙動も他とは異なっている。（具体的には私の本 "Take Control of Using Mountain Lion" をご覧頂きたい。）
文句を言いたい気分になったついでに、第二のチェックボックス「アプリケーションを終了する際にウィンドウを閉じる」に対する私の留保事項もここに書き留めておきたい。さきほど書いた通り、これは実際二つのことをする。グローバルな再開 (Resume) 機能のオン・オフ切り替えをし、アプリケーションの終了がそのウィンドウを第一の「変更内容を保存するか尋ねる」チェックボックスの支配の下に置くかどうかを切り替える。けれどもこれら二つの事柄は、確かに互いに関係はあるけれども、全く同じことではないし、そもそもこのチェックボックスの文言は二つのうちどちらについても極めて正確に言い表わしているとは言い難い。その結果として、この第二のチェックボックスが何をするのかが、どうにも理解し難くなってしまっている。いつもならば極めて注意深い John Siracusa でさえ、Mountain Lion の技術的レビューを書いた記事の中でこのチェックボックスの重要性を完全には見極めていないように見えるし、私自身も Take Control 本の執筆作業の最中にうっかりとそこのところの一部を見逃してしまっていたのだから。
それから、Apple もまた、第一のチェックボックスを完全に正確には実装していない。このチェックボックスには「書類を閉じる際に変更内容を保存するか尋ねる」と書いてある。けれども、もしも書類を開いて編集してから、その後で File > Save As を選べば（間違いなくそれが Save As の最も一般的な使用法だろう）元の書類は変更内容を保存するかどうかを 尋ねずに さっさと閉じられてしまう。新しいファイルに未確認の変更内容があるのは問題ないけれども、古いファイルにも未確認の変更内容はあったのであり、それについて尋ねることなく勝手に閉じてしまうのは明らかに「書類を閉じる際に変更内容を保存するか尋ねる」としたユーザーの要求に反している。奇妙なことに、この点については Lion の方が Mountain Lion よりまともな挙動をしていた。Lion では、編集を施した書類で File > Duplicate を選ぶと、ダイアログが現われて複製の前に元の書類を以前の状態に復旧させる機会が与えられた。ところが Mountain Lion では、そんなダイアログはもはや現われない。
しかしながら、そういったさまざまの問題点はさておき、それでも私はこれら Mountain Lion における現代的書類モデル (Modern Document Model) への変更は歓迎すべきものであり、独創的な工夫に富んでおり、並外れて重大な意味を持つものであると思う。やはり私としては何らかの方法でオートセーブを完全にオフに切り替えることができたら嬉しいとは思うけれど、Apple がそうするのはあり得ないと認めるとしても、Apple は確かに最大限の努力を注ぎ込んで、オートセーブを以前よりずっと多くのユーザーに受け入れられるものへと変えてみせたのだ。たとえ、今はまだすべてが厳密に正しく働いてはいないとしても。私は、David Pogue の考え方には同調できない。Mountain Lion を紹介する New York Times 記事の中で、彼は Lion のオートセーブ機能を「不可解なもの」と（正しく）形容する一方で、Mountain Lion における現代的書類モデルへの変更点についてはこれをたった二つのメニュー項目に過ぎないとして相手にせず、否定的な評価しか与えなかった。けれども私ははっきりと言っておきたい。これらの変更点こそが、Mountain Lion が Lion よりも好ましいことの 主たる 理由なのだと。そして、これらの変更点こそが、これまで Snow Leopard から Lion へのアップデートを本気でしたいとは決して思わなかったユーザーたち（そこには私自身も含まれるが）の気持ちを引き寄せて、Mountain Lion を多かれ少なかれフルタイムで使ってみようかという気にさせられるかもしれない、本質的な要点なのだと。
コメントリンク13187 この記事について | Tweet リンク13187
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Nisus Writer Pro 2.0.4 と Express 3.4.3 -- これら二つのワードプロセッシング用アプリはいずれも最近数多くの変更を受けてアップデートされたばかりだが、Nisus Software は報告の多かった問題点のいくつかに変更を加えて Nisus Writer Pro 2.0.4 と Nisus Writer Express 3.4.3 を新たにリリースした。いずれのアプリも OS X 10.8 Mountain Lion で走らせた際、Apple の Start Dictation メニューコマンドを Edit メニューに表示するようになり、スタイルシート表示でスタイルリストを右クリックした際に起こったクラッシュを修正している。さらに、いずれのアプリも英語以外の言語で正しいハイフン処理をするようにするとともに、Print ダイアログ中のプレビューでクリップしたりズームしたりした際の問題を修正し、ファイルへのリンクにおける問題点を修正し、Draft View でズームイン・ズームアウトした際の「見苦しい」再表示のちらつきを解消している。Nisus Writer Pro については、バージョン 2.0.4 では特殊文字の入った書類を EPUB フォーマットに書き出す際の問題点を一つ修正し、目次の適用対象を含む複数部分の選択範囲をコピーしたりペーストしたりする際のハングを予防し、スタイルにおける段落境界および周囲線のカラーを変更する際の問題点を直している。(Nisus Writer Pro: 新規購入 $79、無料アップデート、159 MB、 リリースノート。Nisus Writer Express: 新規購入 $45、無料アップデート、51 MB、リリースノート。)
Nisus Writer Pro 2.0.4 と Express 3.4.3 へのコメントリンク:
DEVONthink と DEVONnote 2.4 -- DEVONtechnologies が、 DEVONthink の三つの版すべて (Personal、Pro、Pro Office) と DEVONnote をいずれもバージョン 2.4 にアップデートし、OS X 10.8 Mountain Lion の新機能との互換性を盛り込んだ。具体的には、このリリースで通知センターに対応し、Gatekeeper と仲良く働くようになり、共有ボタンを追加して iMessage、Mail、Twitter、Facebook、および AirDrop と書類を共有できるようにした。（また書類を Safari の Reading List に追加できるようにもした。）64-bit にも対応したので、データベースのサイズはメモリが利用可能であなたの Mac のパフォーマンスが対応し得る限り大きくできるようになった。DEVONthink の三つの版とも、Image Capture 互換なスキャナやカメラ（iOS デバイスも含む）からスキャンや画像を読み込めるようになった。従来この機能は Pro Office 版のみのものであった。(すべてアップデートは無料。新規購入は DEVONthink Pro Office $149.95、DEVONthink Professional $79.95、DEVONthink Personal $49.95、 リリースノート。DEVONnote は新規購入 $24.95、リリースノート)
DEVONthink と DEVONnote 2.4 へのコメントリンク:
TextExpander 4.0.1 -- Smile が TextExpander 4.0.1 をリリースした。最近アップデートされたばかりのこのタイピングショートカットユーティリティに、少数の修正や改善を加えたメンテナンス・フォローアップ版だ。今回のリリースではメニューバーアイコンに半透明性が復活し、オプションのセクション穴埋めでチェックボックスのラベルをクリック可能にし、日本語およびイタリア語のローカライズ版でヘルプセクションをアップデートしている。さらに、Symbol グループにある等式の短縮形が等号二つで終わるように (例えば ">==" のように) なった。その他にも詳細は明かされていないが多数のマイナーな修正や改善がある。(新規購入 $34.95、 TidBITS 会員には 20 パーセント割引、アップグレード $15 (ただし 2012 年 1 月 15 日以後に購入の場合は無料)、無料アップデート、8.5 MB)
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
HyperCard はちょうど 25 年前にリリースされた。そこで今週の ExtraBITS ではそれを回顧しようという Twitter リンクを紹介する。また、Dan Frakes が Mountain Lion で新設された Power Nap 機能を解説した記事と、Mat Honan の iCloud アカウントがハッキングされた件に関する詳報もある。（このハッキングの具体的な手法はもはや実行不可能のはずだ。）
HyperCard の 25 周年記念の回顧メッセージ -- 1987 年 8 月 11 日に、Apple は Boston で開催された Macworld Expo において「ソフトウェア組み立てセット」HyperCard をリリースした。今では HyperCard が私たちの身近に見当たらなくなってもう長い年月が経つけれど、当時には HyperCard のお陰で私たち Mac ユーザーの生活が信じられないほど大きく様変わりしたものだ。それまでは日の目を見る手段を持たなかったさまざまのアイデアの多くに、HyperCard が命を与えたからだ。その中には TidBITS さえも含まれる。私たちの最初の 99 号までは HyperCard フォーマットで出版され、毎号が一つずつの HyperCard スタックとして配布されて、そのコンテンツを検索可能なアーカイブの中に読み込めるようにしていたのだ。完全に新しいフォーマットで出版するというスリルに後押しされていなかったなら、TidBITS が創刊間もなく挫折ということもあり得たかもしれない。この Twitter 検索で、他の人たちが投稿したメッセージをスクロールして眺められる。そこに出てくる iPad 用 Infinite Canvas というものにも注目したい！
Dan Frakes による Power Nap 解説 -- Mountain Lion には Power Nap と呼ばれる新機能がある。ただ、それはごく少数の最新のラップトップ機種 Mac でしか利用できないので、おそらくこの機能を目にした人たちは少ないだろう。簡単に言えば、Power Nap によってそれに対応した Mac はスリープ中にごく短時間だけ目覚めて、Time Machine バックアップをしたり、Mail で新着メールをチェックしたり、Messages で新着メッセージを受信したり、iCloud 関係のデータ（カレンダーイベント、連絡先、リマインダー、メモ、iCloud 書類、Photo Stream の写真など）をアップデートしたりできる。私たちの友人 Dan Frakes がこの Macworld 記事で、Power Nap に何ができるか、どうやって使うのか、使えるのがごく少数の機種に限られるのはなぜか、などを解説する。
Apple と Amazon のセキュリティ欠陥により Mat Honan がハッキングされる -- Gizmodo ライターの Mat Honan が、Wired のためにこの記事を書いた。彼自身のデジタル生活の大部分がハックされたのが、Amazon (彼のクレジットカード番号の一部を明かしてしまったため) と Apple (Amazon 詳細情報とその他の公開された情報のみによって彼の人物確認をしてしまったため) 双方のセキュリティ欠陥によるものであったことを説明している。読んでみて非常に興味深いが、私たちが真っ先に減点対象と感じたのは、自分のデータはすべて、Mac 上のものも、iPhone 上のものも、クラウド保存のアカウント上にあるものも、絶対にローカル（手元）のバックアップを持っておかなければならないという点だ。Mat はそれをしていなかったので、彼の生活がオンライン断絶状態となったのは一時的なものかもしれないけれども、彼の Mac が遠隔ワイプされたことで失われたデータは永遠に戻ってこない。
Apple と Amazon がセキュリティ実践方法を変更 -- 詳細はまだ発表されていないけれども、Wired の記事によれば、Mat Honan のデジタル生活が遠隔から乗っ取られることを可能にした比較的単純なハッキングはもはや実行不可能だという。Amazon と Apple の双方が、アカウントに関係したセキュリティ実践方法を（少なくとも一時的に）変更したからだ。両社のポリシーが今後どのようなものになるのかはまだ判明していないが、両社とも何らかの対策を実施しなければならないことだけは明らかだ。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2012 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2012年 8月 22日 水曜日, S. HOSOKAWA