HMDT - Logic and Intuition -

Apple が、Tiger の開発者向けオーバービューとして、Dashboard の情報を公開している。Dashboard はご存知のように、小さい Widget と呼ばれるアクセサリというかアプリケーションのようなものを実現するもの。今回の Apple の記事では、この技術を開発者の視点から紹介している。

この記事で強調されているのは、開発者から見た Dashboard は、素早く作成できて素早く公開できるプラットフォームである、ということ。Tiger の機能を 1 つだけ試してみたいときとか、アプリケーションのちょっと面白いアイディアを思いついたときに、満足に動くアプリケーションを作って公開できるレベルにまで持っていくのは、なかなか大変だ。でも Dashboard なら、さくっと試してさくっと公開、ということができる。なるほど、これは面白い視点だ。つまり、RAD 環境の 1 つとして使ってもいいわけだね。ユーザインタフェースがちょっと限られてしまうけど、それもまたよし。制約があるところから、新しいアイディアが産まれるのはよくあることだ。

他に、記事を読んでいて気になったことをいくつか。まず、Widget は一つずつがプロセスとして扱われるらしい。そして Widget がクラッシュすると、Dashboard Server によって自動的に再起動される。ただし、3 回連続でクラッシュすると、Dashboard から削除されるらしい。ちょっと笑った。きっと、「Widget が自動的に削除されてしまいました」という質問が FAQ になってしまうのでしょう。

あと、Widget は Apple 独自拡張 HTML をベースにしている。具体的には、canvas タグ、img タグの composite 属性、input タグの search タイプが追加されているんだけど、Apple はいまこれの標準化に動いているそうだ。標準化が認められれば、将来 Safari 以外の Web ブラウザで Widget が動く、ということもあるかも。

シイラ Nightly build 041213。

• 環境設定にサイドバーパネルを追加。

サイドバーの初期設定をするためのパネルを追加。サイドバーの位置、自動伸縮を行うかどうか、ブックマークをシングルクリックで開くかダブルクリックで開くか、といった設定が行えるよ。環境設定のアイコンは、テンポラリ。

2、3 日前から、シイラで右クリックをするとクラッシュする、っていうメールがたくさんきて調査しているんだけど、ぜんぜん再現しない。こっちの環境ではまったくクラッシュしないんだけど、他にもクラッシュしている人いますか？

Safari 関係のユーティリティとのコンフクリトかなぁ？前もそういうことあった。

シイラ Nightly build 041209。

• ブックマークのドラッグアンドドロップの問題を修正。
• HTTP リクエストのヘッダを表示。

ブックマークのドラッグアンドドロップは、ソースコードをかなり見直した。いままで、拡張に拡張を重ねて、かなり汚くなっていたのをすっきりさせた。これで、だいぶバグが取れたはず。

もう 1 つの方は、HTML ソースを表示するウィンドウで、いままで HTTP レスポンスヘッダだけを表示していたのを、リクエストも表示できるようにした。これは、リダイレクトのデバッグをしているときに欲しくなったので、付けてみた。また、ブラウザのユーザエージェント名が気になっている人も、ここを見るといいと思う。実際に、サーバに送っているユーザエージェント名を見ることができるよ。

シイラ Nightly build 041207。

• 画像の自動リサイズ機能の問題を修正。

シイラで大きな画像を単体で表示させると、自動的にウィンドウの大きさに合わせる、っていう機能があるんだけど、それに実装上の問題があったのを修正。いままで動いたり、動いてなかったりしてたけど、これで安定して動くと思う。さらに、画像のドラッグアンドドロップができなくなる問題も修正。

実はこの修正、えらくトリッキーなことをやってます。

まずは、状況の説明を。この機能は、Web Kit の画像表示を担当している、WebImageView のサブクラスを作って（WebImageViewEx という名前）、それを poseAs: することで実現していたんだ。それ自体には問題が無いんだけど、困ったのは WebImageView は非公開クラスで、かつシンボルが export されていないということ。WebImageView のインタフェース自体は、class-dump などで知ることができる。でも、シンボルが export されていないと、リンクができない。つまり、ビルドが通らない。これが困った。

以前は、しょうがないからダミーの空っぽの WebImageView クラスを定義して通していた。ただこれだと、1 つの Objective-C ランタイムに同一名のクラスが 2 つ存在することになる。これはまずいよなぁ。知ってたけど、いままでそうしていました。

やっぱりそれはよくない、っていうんで別の解決策を考えてみた。この問題は、ビルドするときに WebImageView のクラス情報を知ることができないから起こる。ということは、だ。起動してからクラスを作ってやればいい！

具体的な手順はこうなる。まず、WebImageViewEx の代わりに、WebImageViewEx_pseudo というクラスを定義する。これは、WebImageViewEx と同じ実装だけど、WebImageView じゃなくて、NSView を継承している。

このクラスのビルドは通る。そしてアプリケーションが起動した後、WebImageViewEx_pseudo の load の中で、WebImageViewEx を作ってやる。インスタンスを作るんじゃなくて、クラスの定義を作るんだ。この時点なら、WebImageView がロードされているので、このクラスの情報を知ることができる。

動的なクラスの作成の手順は、この「Objective-C プログラミング言語：objc_addClass」を参照するといい。クラスの定義をあらわす objc_class 構造体を作ってやって、objc_addClass を呼べばいい。今回は、さらにその後に class_poseAs も呼んでいる。

これで実現できた！正直な話、えらくダーティでアクロバティックな方法だ。Apple が WebImageView のインタフェースを公開していれば、それで済んだ話なんだけど。でも、こういうハックはすごく楽しい。Objective-C は、自身のランタイムが C で書かれていて、それに制約なくアクセスできるから、可能な話だ。この辺が、柔軟な開発環境と呼ぶこともできるし、言語としては汚いと呼ぶこともできるか。

Apple が Technical Note 2124: Mac OS X Debugging Magic を公開している。これは、いままでドキュメント化されていなかったものが多かった、デバッグに関する情報をまとめものだ。とても使える情報がたくさんあるよ！

カバーしているライブラリも広範囲で、CrashReporter、BSD、Core Services、ディスク、印刷（CUPS）、ApplicationServices、Carbon（HIToolbox）、そして Cocoa が含まれている。現在アプリケーションの開発を行っている方には、強く一読をお勧めしますよ。

ついでなので、Cocoa のセクションに関する要約を作ってみた。

Mac OS X Debugging Magic: Cocoa

• GDB のシェルで、print-object コマンド（または po）を使うと、オブジェクトの description メソッドを呼び出すことができる。

- Foundation

• Foundation の NSDebug.h には、デバッグで使用できる環境編集が定義されている。それらは、ゾンビオブジェクトや NSAutoreleasePool に関するデバッグに利用できる。

- AppKit

• NSQuitAfterLaunch 環境変数を 1 に設定しておくと、アプリケーションが起動してイベントループに入ったときにすぐ終了させることができる。起動時間を計ったり、起動時のメモリリーク調査に利用できる。

- AppKit イベント

• デフォルトデータベースで NSTraceEvents を YES に設定しておくと、イベントに関する情報をすべてログとして表示する。
  例：
  % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSTraceEvents YES

- AppKit ビュー

• デフォルトデータベースで NSShowAllViews を YES に設定しておくと、すべての AppKit のビューが枠線を表示する。
  例：
  % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllViews YES
• デフォルトデータベースで NSShowAllDrawing を YES に設定しておくと、すべての AppKit のビューで、描画するとき一瞬フラッシュする。値として数字を設定することで、フラッシュする時間を変更できる。デフォルトは 100ms。NSShowAllDrawingColor に、'0.0 1.0 0.0' のように RGB 値を設定すると、色を変えることができる。さらに "CYCLE" という文字列を設定すると、周期的に色が変更するようにもできる。
  例：
  % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing YES
  % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing 500
  % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing YES -NSShowAllDrawingColor CYCLE

- その他

• デフォルトデータベースで NSDragManagerLogLevel に数値を設定すると、ドラッグアンドドロップのログを表示する。
• デフォルトデータベースで NSAccessibilityDebugLogLevel に数値を設定すると、AppKit のアクセスシビリティ API のログを表示する。

以上。きっとどこかで役に立つことでしょう。

IE のお気に入りを読み込むための、長い道のり。

いまさらながら、Internet Explorer のお気に入りファイルを読み込むプログラムを書こうとしている。すでに多くの方がご存知のように、IE のお気に入りは、~/Library/Preferences/Explorer/Favorites.html に書き出されているんだ。これは Netsacpe Bookmark File Format っていうのと互換で書かれているらしい。簡単な説明がここにある。一言で言うと、HTML ファイルとして保存してある訳だ。ガッデム。再利用するときにめんどくさいじゃないか。XML にしろよ。

文句をいってもしかたがないので、どうにかすることを考える。まず、HTML ファイルをパースしないといけない。これは Cocoa ではできない。Web Kit を使うか？WebView を作成して、HTML ファイルを読み込ませて、DOM ツリーを取得。これならできそうだけど、たかがお気に入りファイルを読むために、そこまでやるのはおおげさすぎる。Web Kit の HTML パーサに直接アクセスできればいいんだけど。で、検討の結果、libxml2 を使ってみることにした。

libxml2 は、XML を取り扱うためのライブラリ。Panther あたりから、Mac OS X に標準で付いてくる（これ重要）。HTML のパーサもついている。次のようなコードで、HTML をパースしてツリーを得ることができる。

#include <libxml/HTMLParser.h>
#include <libxml/HTMLTree.h>

int main(int argc, char** argv)
{
    htmlDocPtr htmlDoc;
    htmlDoc = htmlParseFile(
        "/Users/mkino/Library/Preferences/Explorer/Favorites.html", NULL);
}

おぉ、簡単だ。htmlParseFile を呼べばよろし。どのくらいの HTML ファイルに対応しているかは分からないけど、IE のお気に入りはとりあえず読み込めるようだ。

あと、エンコーディングも取得できる。HTML ファイルに、charset でエンコーディングが指定してある場合は、 htmlGetMetaEncoding で取得できる。

次に、このツリー構造を解析する。解析の仕方は 2 つ。1 つは、一個ずつ手でたぐっていく方法。もう 1 つは XPath を使う方法だ。XPath を使えば、ダイレクトに目的のノードにアクセスできる。たとえば、IE のお気に入りだと、トップ階層にあるフォルダは、HTML の body 要素の下の、dl 要素の下の、dt 要素の下の、h3 タグとして表現されている。これにアクセスするコードは、次のような感じになる。

void getFolder(htmlDocPtr htmlDoc)
{
    xmlXPathContextPtr  context;
    context = xmlXPathNewContext(htmlDoc);
    
    xmlXPathObjectPtr   result;
    result = xmlXPathEvalExpression(
            (xmlChar*)"/html/body/dl/dt/h3", context);
    xmlXPathFreeContext(context);
    
    xmlNodeSetPtr   nodeSet;
    nodeSet = result->nodesetval;
    if (!xmlXPathNodeSetIsEmpty(nodeSet)) {
        int i;
        for (i = 0; i < nodeSet->nodeNr; i++) {
            xmlNodePtr  nodePtr;
            nodePtr = nodeSet->nodeTab[i];
            
            printf("name %s\n", nodePtr->name);
            printf("content %s\n", xmlNodeListGetString(
                    htmlDoc, nodePtr->xmlChildrenNode, 1));
        }
    }
    xmlXPathFreeObject(result);
}

HTML ツリーに対して、/html/body/dl/dt/h3 っていう XPath を評価する。これで h3 タグの一覧が得られる訳だ。

XPath は便利だけど、今回のお気に入りの読み込みではフォルダをたぐるため、再帰的にアクセスする必要があるので、手でやった方が効率がいいかもしれない。これで、どうにかタイトルとアドレスは得ることができそうだ。

さらなる問題。お気に入りのフォルダには、通常のフォルダと、お気に入りツールバーとして使われる特殊なフォルダがある。これをどうやって見分けるか？結論から言うと、フォルダの名前から見分けるしかない。がーん。

名前で見分ける場合の問題は、ローカライズへの対応だ。「お気に入りツールバー」という文字列を使ってしまうと、あたりまえだけど、日本語環境でしか動かなくなる。じゃ、どうするかというと、あらかじめすべての言語用の名前を持っておくしかないか。

IE アプリケーションのパッケージを開いて、Resources のフォルダをのぞくと、各国ローカライズの .lproj フォルダの下に、デフォルトのお気に入りファイルがある。それを開いて、ツールバーのフォルダに使われている文字列を調べて、持っておくしかないな。うーん、不格好だ。

結論。Netscape Bookmark File Format は、いや。

いま思い立って、Firefox を調べてみたら、こいつも Netscape 形式なの。やめてー。

昨日の Safari 1.3 の話で書き忘れたことが一つ。Safari 1.3 は XSLT に対応する。ということは、きっと libxslt がインストールされるはず。これで、自分のアプリでためらうことなく XSLT が使えるようになる。いやっほう。

ローラン株式会社のMac OS 技術情報で、Cocoa プリンティングの翻訳が公開されています。原文はこちら。

このドキュメントは、Cocoa アプリケーションから印刷機能を使うための情報の、ほとんどをカバーできるもので、ドキュメントを扱うアプリケーションを作るときは必読です。とても有用な情報なので、どんどん読みましょう、および公開ありがとうございました。

Safari 1.3 のリリース間近、っていう情報があちこちで流れてるねー。

新しい Safari も楽しみなんだけど、Web Kit 使いとしては、Safari 1.3 とともにアップデートされる Web Kit が待ち遠しい。今度の Web Kit のバージョンアップは、おそらく去年の公開以来最大のものになりそうで、Web Kit 2 って呼んでもいいぐらいのインパクトがあるんじゃないかと思ってる。

新しい Web Kit では、編集機能や DOM アクセスやページアーカイブといった機能が追加されているはず。これによって、Web Kit アプリケーションは、いままでは文字通り「ブラウザ」としての機能しか持てなかったのが、「エディタ」として大きく様変わりできることになる。いやー、面白そう。これでシイラにがんがんといろんな機能を突っ込めるのだ。

シイラ Nightly build 041201。

• 認証できない証明書を、とりあえず受け入れるためのダイアログを表示。

いままでは、ログインするときに証明書が使われるサイトで、「証明書に未知のルートが含まれています」とかなんとか言われて、入れなかったことがあったと思う。その問題を対策した。ダイアログが表示されて、とりあえず現在の証明書を使うなら、「続ける」をクリックすることで次に進めるようにした。

で、この問題だけど、前にも書いたように、Web Kit というか Mac OS X が、渡された証明書の妥当性を決定できない、というのが問題。原因はいろいろあって、証明書が Mac OS X が認めている機関が認証していないとか、期日が切れているとか、データがおかいしとか、そんな感じらしい。実は、あまりよく理解していない。

この認証は、Web Kit より下のレイヤで行われているらしい。だから、Web Kit を使っているアプリケーションにはエラーだけが通知されて、おしまい。これじゃ、読み込みを続けることができねーよ。

でもやはり同じところでひっかかっている人はいたようで、Google で探すとこんな ML のアーカイブにたどり着いた。”NSURLConnection and self-signed certs.”証明書のエラーが返ってくるんだけど、これをどうやって無視すればいいの？と。

いろいろな話が出ているけど、結論は 2 つ。まず、この認証は Secure Transport ライブラリを使っている。だから、それに含まれる SSLAllowsAnyRoot API を呼んでやればいい。これですべての証明書が許可される。なるほど、低レベル API を使った正攻法だ。でもめんどくせーな。

もう 1 つの方法は、NSURLRequest の隠し API である、setAllowsAnyHTTPSCertificate:forHost: を使うこと。おいおい、そのものずばりじゃないか。これを呼べば一発だ。ということで、シイラではこちらを利用することにした。

しかし、これって結構重要な API だよな。これが公開されていないってのは、ひどくないか Apple？Safari はたぶん使っているだろうし。この辺は、実際に組んでみないと分からないとこだよな。