Latest topics 近況報告

Fennec合宿の成果まとめ - Jun 16, 2009

bugzilla上での活動？としてはこんな感じでした。

• Bug 441590 – can't scroll maps.google.com：コメントしただけ。
• Bug 460966 – mousover css drop down menu doesn't work with fennec, but works with iphone：パッチ書いてみたけど、その後中野さんに相談して、より根本的な解決を図る方法としてイベント周りに変更を加えるパッチを書いてもらった。ただ、今投げてあるパッチだとよく分かってない開発者に「これ、いらなくね？」とうっかり削除されてしまいかねなさそうな感じらしいので、書き直したいとのことだった。
• Bug 476703 – When switching tabs, use the last pan x, y offsets：パッチ書いて、レビューで+を貰ったけど、同時に一箇所指摘を受けていて、もう一度レビュー申請中。→review+になってチェックインされた。
• Bug 480962 – zoom level is reset when clicking on a download link：パッチ書いたけどレビューで-になった。とりあえず指摘された点のうち表面的な所だけ直してパッチを再投稿したけど、もっと根本的な解決を図った方がよいのだろうか。
• Bug 483529 – clicking on a downloadable link causes fennec to misdraw page's content.：コメントしただけ。
• Bug 489127 – ElementFromPointWithArea required for better usability on mobile devices.：コメントしただけ。
• Bug 493845 – Cannot scroll choices in a <select> tag using size attribute：パッチ提出したけど、似たようなバグで同じ所をいじってるからそっちで何とかしたいということでレビューがキャンセルされた。
• Bug 494715 – When panning the content and switching tab, viewport can be wrong：Bug 476703を直そうとしてぶち当たった。すでに他の人が作業してたけど、止まってるみたいだったから空気読まずにパッチ投げた。レビュー申請中。
• Bug 496874 – Oracle documentation page rendered twice：原因を調べて、テストケースとアドホックな対応のパッチを投げた。レビューは申請してない。

成果らしい成果は……パッチが1つだけreview+をもらえたチェックインされたことくらいでしょうか。

コメントも何もしてないけど、目を付けたバグ。

• Bug 464984 – find in page highlights words, but doesn't scroll if they are not in the current view：ページ内のスクロールが一切機能しない、というバグ。Bug 452286 – content scrolling itself and anchor link clicks don't cause a redrawはこれのduplicated扱いになっている。すでに他の人が作業をしてるので静観。
• Bug 480958 – unable to scroll content when it dynamically is expanded：ページの高さが変わった後に、元の高さよりも先の部分にスクロールできない問題。他の人が作業してるようだったので静観。

感想。Fennecが実用レベルになるのはまだまだまだまだまだまだまだ先だなあ。

というか今Fennecという名前で開発されているブツは、Mozilla Labsが作る新しいUIデザインのモックアップに過ぎない、という風な位置づけのように感じられる。バックエンドで使ってるXULRunnerはモバイル向けの調整が施されていなくて、印刷関係の機能とか、明らかに不要な物がてんこ盛りになっている。中野さん達と色々話したけど、「実用になる製品」の開発を目指すんだったら、僕がこういう風に手出しできるレイヤでゴチャゴチャと小賢しいことをするんじゃなくて、中野さんに書いて貰ったパッチのように、XULRunner自体の方にもっともっと手を入れていく必要があるのだろう。HTML Canvasを描画に使ってるせいで色々酷いことになってるのも、Canvasに手を入れるかDocShellに手を入れるかして、ネイティブ寄りの所で実現するようにすればずっとマシになるはずなのに。とかなんとかそういう「うわぁ……」な現状が色々見えてきたのが、今回の合宿の一番の成果だったのかもしれない。

Illustrator CS4でアートボードの大きさでPNG出力する手順 - Jun 11, 2009

世間的にすごい今更だと思うけど、今日やろうとして詰まったのでメモしておく。

Illustrator CS2を使ってた時は、以下のような感じだった。

• 何も考えずにPNG出力しようとすると、アートボード（用紙サイズ）より外側にあるオブジェクトまで含めたドキュメント全体をPNG出力してしまう。
• 何も選択してない状態で「オブジェクト」→「クリエイト」→「トリムマーク」とすると、アートボードのサイズのトリムマークが表示される。この状態でPNG出力すると、アートボードの範囲の内容だけがPNG出力される（それ以外の部分はトリミングされる）。

しかしIllustrator CS4では、「オブジェクト」メニューに「クリエイト」が無い。

• 代替の機能は「効果」の方の「トリムマーク」らしいんだけど、何も選択してない状態でこれを実行しても何も起こらない。
• 何かオブジェクトを作ってそれにこの機能でトリムマークを付けてみても、PNG出力の時の結果は変わらない（アートボードの外側まで出力されてしまう）。

実は、IllustratorはCS4から複数のアートボードをサポートするようになって、印刷や出力の基本単位はアートボードごとということになっているらしい。なので以下のようにすれば、CS2の時の結果と同様、アートボードの大きさでトリミングされたPNG画像を得ることができる。

• 「書き出し」を選択して、表示されるファイルおよび出力フォーマット選択のダイアログが表示されたら、まずファイル形式としてPNGを選択する。
• 次に、ダイアログの左下にある「各アートボードごと」にチェックを入れる。（ダイアログを開いた直後に選択されている形式では、このチェックボックスがグレイアウトしている）
• ファイル名を入力して「保存」をクリックすると、アートボードの大きさにトリミングされたプレビューが表示される。そのまま確定すれば、プレビューの通りにトリミングされたPNG画像を得られる。

ということでこの件については解決された。しかし「アートボードとぴったり同じ大きさの矩形オブジェクト」を作るのが面倒になったのはやっぱり頂けない（CS2だと、トリムマークを作ってそのまま解除すれば、アートボードと同じ大きさの矩形オブジェクトを得ることができた）。

AMOのコレクション機能を使ってみた - Jun 10, 2009

AMOを見たらリニューアルされてて、好きなアドオンを集めたリストを公開できる「コレクション」という機能が加わってたので、さっそく使ってみた。

PiroがFirefoxで常用してるアドオン :: Firefox Add-ons

デスクトップ百景の時のリストのアップデート版といった感じ。AMO上に無い物を入れられないため、いくつか抜けがある。

アドオン開発用ツール集 :: Firefox Add-ons

デスクトップ百景の時の物のうち、アドオン開発用の物だけ。プラスいくつか。

タブブラウザ拡張3 :: Firefox Add-ons

メタパッケージはAMOに置けないので、作ってみた。

PiroがThunderbirdで常用してるアドオン :: Thunderbird Add-ons

Ubuntu上のThunderbirdで利用してるアドオン。他に自分で作ったパッチも入れている。

リストアップされたアドオンをボタン一発でまとめてインストールできる機能だとばかり思ってたんだけど、そういう機能はなくて、入れたかったらいっこいっこ個別にぽちぽちインストールしないといけない。これは面倒すぎる。なんで一括インストールできるようにしなかったんだ？　方法はいくつかあるだろうに。

DOM周りの根っこの所に変更が入ったみたい - Jun 10, 2009

The Burning Edge見てたら、こんなバグがFIXEDになっていた。

• Bug 468708 – namespaceURI for HTML elements should be http://www.w3.org/1999/xhtml
• Bug 468692 – localName should return in lower case for HTML

text/htmlなHTMLドキュメントをXMLとして扱うにあたって、HTML5の仕様に合わせる形になるという事のようだ。namespaceURIがnullから"http://www.w3.org/1999/xhtml"へ、localNameがすべて大文字からすべて小文字へ、それぞれ変わる、と。

以前の挙動は以前の挙動で古い仕様には合致していたはずなので、時代の移り変わりをしみじみと感じる。

クレジットカードの認証で蹴られた - Jun 10, 2009

もえじら組のバナー画像を夏コミに合わせて更新しなければ→VistaでIllustrator CS2マトモに動かないんだよね……→そろそろCS4買いますか。ということでカカクコムで探してクレジットカード決済のできる店のひとつだったNTT-X Store（初めて使う店）で注文しようと思ったら、カードの情報を正しく入力してるはずなのに認証に失敗する。3回やり直したら「この決済方法は使えません。他の方法を選んで下さい」なんて言われたし。

で、諦めてそこよりちょっとだけ値段が高かったAmazon（言うまでもなくいつも使ってる）で深夜に注文して、昼間に決済手続きが行われたようなんだけど、「クレジットカードで認証できませんでした」という警告っぽいメールがAmazonから届きまして。なんじゃこりゃどういうこっちゃ、とカード会社のコールセンターに電話して聞いてみた。

• 詐欺や不正利用を防ぐために、普段の利用状況と大きく異なる額の利用があると、自動認証を蹴ることがある。（って言われたけど、こないだDELLのPC買った時は一括払いでいけたんだけどなあ……）
• 今後も、このようなことが起こる可能性はある。その場合、その都度コールセンターに連絡して制限を解除してもらわないといけない。

めんどくさ……

ちなみにAmazonの方は、そのあと認証を勝手にやり直してくれたのか無事決済できたようで、当日のうちに発送された。

nsIHttpProtocolHandlerに対するプロキシとなるXPCOMコンポーネントを実装してみた - Jun 08, 2009

ローカルプロキシっぽいことをローカルプロキシを立てずにやろうとして挫折したことのまとめを書いたら、thorikawaさんが別のアプローチを提示してくださったので、その方向で頑張ってみた。

結論から言うと、URIの置き換え（特定のURIにアクセスしようとした時に、別のURIのリソースの内容を返す）についてはできるようになった。成果はUxU 0.6.0に組み込んである。ただし、他のアドオンとの競合の可能性があるので、初期状態では機能を無効にしてある。

実装がどうなっているかはGlobalService.jsの中のProtocolHandlerProxy、HttpProtocolHandlerProxy、HttpsProtocolHandlerProxyの各クラスを参照のこと。thorikawaさんのエントリに挙げられている課題は、一応解決されているはず。

thorikawaさんによるコードからの違いは以下の点だ。

変更点1：元のコンポーネントが実装しているインターフェースは全部備えることにした

一つは QueryInterfaceの部分で、QueryInterfaceの部分を置換前のXPCOMに丸投げしてしまっているので、その後の個別の処理も全て置換前XPCOMで行われてもよいはずです。だけど実際にはnewURI,newChannelといったメソッドは置換後のXPCOMのものが呼び出されます。

QueryInterface()は、実はメソッドの返り値を見るまでもなく、メソッドを実行した時点でそのラッパーオブジェクト自体が変更される。なので、そのせいじゃないかと思う。例えば

var pref = Cc['@mozilla.org/preferences;1']
            .getService(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);

このコードは

var pref = Cc['@mozilla.org/preferences;1']
            .getService();
pref.QueryInterface(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);

と書いてもちゃんと動く。後者のような使い方をされている限りは、QueryInterface()で何を返していようと関係ない、ということではないのかなあ。

C++で書かれたコンポーネントの中ではdo_QueryInterface()という関数？がよく使われているようで、こいつが中で何をやってるのかまでは僕にはよく分かってないけど、上記の例の前者ではなく後者に相当するものなんだったら、引用部のような現象が起こるのではないかと思う。

ということでそういう場合に備えて、ProtocolHandlerProxyクラスは、コンポーネント「{4f47e42e-4d23-4dd3-bfda-eb29255e9ea3}」が備えているすべてのインターフェースを実装しておくようにした。具体的には、nsIHttpProtocolHandler、nsIProtocolHandler、nsIProxiedProtocolHandler、nsIObserver、nsISupports、nsISupportsWeakReferenceの各インターフェース。といっても、やってることとしてはやっぱり単に元のコンポーネントに処理を丸投げしてるだけなんだけど。

変更点2：プロパティとしてアクセスされる情報を、prototypeの方に定義するようにした

またもう一つは、このサンプルでも正常に動作しないサイトがいくつかあること。AJAXを多用しているサイトでも基本的には問題なく動くのですが、たとえばGMailにアクセスするとなぜか簡易版HTMLが表示されてしまいます。もしかすると上記の問題と関連しているのかも知れません。

これは推測だけれども、HTTP_USER_AGENT等が正常に送られなくなっていたせいではないかと思われる。

ちゃんと調べたわけではないんだけど、Webページ内のスクリプトのnavigator.userAgentの値や、HTTPの通信の際に送られるユーザエージェント名の文字列は、コントラクトIDが@mozilla.org/network/protocol;1?name=httpであるコンポーネントがnsIHttpProtocolHandlerインターフェースを通じて返す値を元に生成されているらしい。

然るに、thorikawaさんによるサンプルコードのコンポーネントにはnewChannel()などのメソッドは定義されているけれども、nsIHttpProtocolHandlerが持つはずのuserAgent等のプロパティは定義されていない。XPConnect経由でこのコンポーネントにアクセスすると、undefinedが文字列にキャストされて空文字として返ることになる。その結果、サーバに送られるUA文字列も空っぽになってしまう。つまりサーバから見たら未知のUAとなってしまう。GMailにアクセスするとなぜか簡易版HTMLが表示されてしまうのは、未知のUAに対しては簡易版HTMLを返すようにGMailが作られているからではないかと僕は推測している。

変更点1で書いた話を実施するにあたって、当初はこれらのプロパティもgetterとして定義してみてたんだけど、実際に動かしてみると、期待通りには動かなかった。具体的には、Webページ内のスクリプトからnavigator.userAgent等にアクセスしようとすると、セキュリティの制限により前述のgetter関数を実行できない、というエラーが出る。

なので、getter関数を使うことは諦めて、ProtocolHandlerProxyクラスのプロトタイプに、単純な文字列や数値の定数プロパティとしてそれらを設定しておくようにした。general.useragent.* 系の設定の変更を動的に反映しないといけないので（ここでgetterを使えないのが痛い）、とりあえず今のところは、それらの設定の変更を常時監視して、変更があればその都度ProtocolHandlerProxyクラスのプロトタイプの定数プロパティの値を更新するようにしている。

変更点3：https:なURIに対しても働かせるようにした

この実装では、ProtocolHandlerProxyをスーパークラスとして、HttpProtocolHandlerProxy、HttpsProtocolHandlerProxyという2つのサブクラスを定義することにした。これらの違いは単にコントラクトIDだけ。（まあ、モジュールを登録する時にしか使わない情報なので、サブクラスにするまでもなかったんだろうとは思うけど……）

変更点4：このコンポーネントを使うかどうかをユーザが設定できるようにした

コントラクトIDが@mozilla.org/network/protocol;1?name=httpであるコンポーネントを入れ替える事を考えた時に、一番問題になるのはおそらく、同じ事をしようとするアドオンが2つ以上あった時のことだと思う。テストケース内でリクエストされるURIをリダイレクトするためだけに、いつもコンポーネントを入れ替えた状態にしておくというのは、無駄にリスクを高めるだけのような気がする。なので、必要な時にだけ機能を有効化できるようにしてみた。

当初は、NSGetModule()が返すモジュールのregisterSelf()メソッドの中でregisterFactoryLocation()している箇所を、設定値を見て必要に応じスキップするようにすればいいだろうか、くらいに考えていた。でも2つの理由でこれはうまくいかなかった。

1. コンポーネントを登録する処理が走る段階では、プロファイルが初期化されていないので、ユーザが設定を有効にしているのか無効にしているのかが分からない。
2. コンポーネントの登録はUxUをインストールまたはアップデートした後に1回行われるのみなので、ユーザが設定を変更しても即座には反映されない。

1の問題をもう少し具体的に書くと、例えばこのコンポーネントの有効無効をextensions.uxu.protocolHandlerProxy.enabledといった名前の設定で切り替えるようにしようと思っても、NSGetModule()が返すモジュールのregisterSelf()メソッドが実行される段階ではまだユーザプロファイル内に保存された設定値が読み込まれていないため、その段階でextensions.uxu.protocolHandlerProxy.enabledの値を取得しても常にデフォルト値（＝false）となってしまう、ということ。

これを回避するためにUxUでは、設定値ではなくファイルを使うことにした。プロファイル内に「.uxu-protocol-handler-proxy-enabled」という名前のファイルがあればコンポーネントを有効に、ファイルがなければコンポーネントを無効に、という風に、ファイルの有無を真偽値型の設定代わりに使うようにしている。泥臭いというか非効率的というかすごく馬鹿っぽいというかそんな気がするけど、これ以上にいい方法を僕は思いつけなかった。

2の問題は、1を解決できたとしても発生する。Firefoxは利用可能なXPCOMコンポーネントのデータベースをプロファイル内にcompreg.datとxpti.datとして保存しているようで、これらのファイルを生成する時にNSGetModule()が呼ばれるんだけれども、毎回起動時にこのデータベースを作り直していたら無駄が大きすぎる。ということで、アドオンが追加・削除された時などの「コンポーネントの一覧に変更があった可能性がある」場合にだけ、有効なコンポーネントの一覧のデータベースが作り直されるらしい。UxU的には、プロトコルハンドラの乗っ取りのON/OFFを切り替えた後に必ずこのデータベース再作成の処理を走らせないといけない、でもそれができてない、ということだ。

で、これも似たような方法でアッサリ解決した。Firefoxはユーザプロファイル内に「.autoreg」という名前のファイルがあると（ファイルの有無しか見ないので、内容は何でもいい。空ファイルでよい。）、必ずcompreg.datとxpti.datを再作成する。なので、ユーザが設定を変更したらそのタイミングで「.autoreg」を作成してやり、次に起動した時には設定の変更が確実に適用される（コンポーネントが有効かあるいは無効化される）ようにした。

んで

これだけごちゃごちゃと妙なことをやっておいて、できることといったら単にURIをリダイレクトするだけなんだよね。ショボっ！

撃ち尽くし - Jun 07, 2009

気がついたら手持ちの弾を全弾撃ち尽くしてた……という感じ。もうどこをひっくり返しても何も出てきませんわ。

プラットフォームのデフォルトの文字エンコーディングを取得する方法を調べようとして挫折したことのまとめ - Jun 06, 2009

ソース表示タブの障害として、「外部のテキストエディタを使う設定にしてる時に、Windowsのアカウント名が日本語だったりするとファイルを開けない」という報告を受けた。それを修正しようとして挫折した。以下はそのまとめ。

Webページのソースをテキストエディタで開く処理について

当該機能は実はソース表示タブ自身が提供しているわけではなく、Firefox 2以降くらいからFirefox自体に元々備わっている隠し設定のための設定UIを提供しているだけで、実際の処理はFirefox本体の物に丸投げしている。具体的にはviewSourceUtils.jsのopenInExternalEditor()とかそこら辺。

ただ、Firefox本体のこのコードは国際化のことをきちんと考えられていないようで、テキストエディタの実行ファイルのパスに日本語の文字などが含まれているとダメという既知のバグがある（原因はgetExternalViewSourceEditor()の中でgetCharPref()で取得したパス文字列をUTF-8バイト列からUCS2のUnicode文字列に変換していないせい）。なのでソース表示タブではこの部分に動的にパッチを当てる形で問題を回避するようにして、もう少し実用に耐えるようにしようとしてみている。

今回の問題の原因は、エディタの実行ファイルではなく、開こうとしている対象のファイルのパスの扱いにある。

Firefoxは、ソースを表示しようとしている対象がローカルのファイルだとそれをそのまま、Web上のファイルであればそれをダウンロードしたテンポラリファイルを、エディタに渡そうとするんだけど、どうもその時にnsIProcessのrun()メソッドで渡す引数がUCS2のままなのがいけないらしい。試しに自分の環境（Windows Vista日本語版）で試したところ、引数のeditor.run(false, [path], 1);とか書かれてる箇所で渡されてるパス文字列をnsIScriptableUnicodeConverterあたりでShift_JISに変換してやったらうまく動いた。IDL定義ではstringの配列としか書かれてないけど、ここはプラットフォームごとのデフォルトの文字エンコーディングにしておかないといけないようだ。

実験段階で明らかなように、nsIScriptableUnicodeConverterで適切なエンコーディングに変換してやれば問題は解決できる。残る問題は、じゃあ一体どのエンコーディングに変換すればいいのか、ということだ。

設定UI上にエンコーディング選択用のドロップダウンリストを付けるという手もあるけど、ユーザにそんな事を意識させるのはダサイ。なるべくなら自動で判別できるようにしておきたい。ということでその方法を模索してみた。

nsIFileのnativePathから辿ってみた

現在のFirefoxでは、ローカルファイルはnsIFileインターフェースで処理されている。このIDL定義を見ると、プラットフォームのデフォルトのエンコーディングでのパス文字列をそのまま保持しているとおぼしきnativePathプロパティの定義には[noscript]と書かれていて、JavaScriptからはアクセスできないようになっている。実際、試してみても無理だし。

ちなみに、昔おそらくnsIFileの代わりに使われていたと思われるnsIFileSpecだとnativePathには[noscript]が付いてない。なので、これを使ってやればいいか？と思ったけど、リンク先のソースの位置を見ると分かる通りこれは既に廃止されたモジュールで、今のFirefoxのバイナリには入ってないっぽい。インスタンスを作ろうとしてもエラーになる。

nsIFile/nsILocalFileを実装してるWindows用のコード（nsLocalFileWin.cpp）のGetNativePath()の定義を見ればヒントを掴めるんじゃないか？と思ってみてみたら、CopyUnicodeToNativeという関数？が使われてた。コードが書かれてるnsNativeCharsetUtils.cppを見てみると……おおお、なんか答えっぽい物があるぞ。ifdefでプラットフォームごとに関数の中身の定義をそれぞれ変えてて、例えば頭の方を見てみると、Mac OS XとBeOSでは単純にUTF-8に変換してるという事が分かる。

ただ、下の方に書いてあるWindows用とUnix/Linux用の処理は、見ても訳が分からんかった……単純にこのエンコーディングに決め打ち、という訳にはいかないみたいで、ここからさらに色んな所のコードを見に行かなきゃいけないようだったので、この時点で挫折した。

nsIScriptableUnicodeConverter関係から辿ってみた

nsIScriptableUnicodeConverterはエンコーディング名を指定してUCS2との間で相互変換するものだけど、その時に「プラットフォームのデフォルトのエンコーディング」を指すようなキーワードがあったりしないしないか？と思って、そっち関係のコードも見てみた。

nsICharsetConverterManager.idlとかnsUConvModule.cpp見てて、どこをどう辿ったのか忘れたけど、GetDefaultCharsetForLocale()というメソッドがnsIPlatformCharset.hで定義されているという所まで辿り着いた。

メソッド名から見て、ロケールを指定しないといけないようだけど、それさえなんとかなればこれでいけるか？　と思ってこれにJavaScriptからアクセスできないか試してみたけど、ダメだった。Components.classes['@mozilla.org/intl/platformcharset;1']にはアクセスできるんだけど、QueryInterface(Components.interfaces.nsIPlatformCharset)してみたら「そんなインターフェースねえよ」と怒られてしまった。検索してみても、どうもC言語用のコードしか無いみたい。

結論

無理でした。以上。

C（C++？）を書けるようになって、上で辿り着いたメソッドの実行結果を返すだけのコンポーネントでも書けば、サクッと解決できるのだろうか。もう勉強するしかないのか？

おまけ：文字コード選択のUI

コンテキストメニュー拡張で使ってるけど、文字コードを選択するドロップダウンリストは以下のようにすれば作れる。

<menulist id="charset"
  label="(choose an charset)"
  datasources="rdf:charset-menu"
  ref="NC:DecodersRoot">
  <template>
    <menupopup>
      <menuitem uri="..."
        label="rdf:http://home.netscape.com/NC-rdf#Name"
        value="..."/>
    </menupopup>
  </template>
</menulist>

ただし、XULにこれを書いただけだと空のリストになってしまう。onloadとかそこらへんでCc['@mozilla.org/observer-service;1'].getService(Ci.nsIObserverService).notifyObservers(null, 'charsetmenu-selected', 'other');とすればポップアップの中身が生成される。設定ダイアログで使う時なら、その後でpreference要素のvalueを見るなどして、前回の選択状態を復元してやる必要がある。

ATOK X3の電子辞書の表示がUbuntu 9.04でぶっ壊れる問題が修正された - Jun 04, 2009

ATOK X3の同音語用例・電子辞典ウィンドウが… - めも (2009-04-07)

この問題についてTwitterで発言したまさに翌日、修正モジュールが公開された。吹いた。

tarの中身は問題の原因になってるライブラリの修正版のバイナリファイルで、ルート直下で展開するとデフォルトのインストール先にあるファイルが上書きされる。他の修正パッチを全て適用した後で別途導入する必要があるようだ。

溜め込んで苛々を抱えるのに耐えられない - Jun 02, 2009

ので、ぶちまけた。

我慢したり、腹に沈めたりってことがどうにもできない。ストレス耐性、やっぱり低いなあ。「まだやめとこう……もうちょっと待とう」ってつい先日思ったばかりなのに。

まあ後悔はしてないんですけどね。スッキリした感が強い。ある意味「どうにでもなーれ」なのかもだけど。その辺は、前より結構自分でも「変わったなあ」と思える部分だ。

いや、多分本質的には変わってない。ただ、「まあ最悪の状況になってもそんなに酷いことにはならんな」と、そういう風に考えられるようにはなったんだと思う。プッチ神父の言うところの「覚悟」とかそんなん。