ヘチマ_BLOG

Safari 2.0 で、RSS などを feed: プロトコルで表示するときの、テーマの変更方法が分かった。
デフォルトのテーマはここにある。
/System/Library/PrivateFrameworks/SyndicationUI.framework
/Versions/A/Resources/Themes/default.syndtheme
もしくはこちら。
/System/Library/PrivateFrameworks/SyndicationUI.framework
/Themes/default.syndtheme
これを
/Users/あなた/Library/Syndication/Themes
というフォルダを作ってその中にコピーする。Syndication フォルダは、取得した feed のデータベースのために作成されているはずだ。
コピーした default.syndtheme のフォルダ名を変更する（例：sample.syndtheme）。 sample.syndtheme/Contents/Info.plist を Property List Editor（推奨）かテキストエディタで開いて、「CFBundleName」をフォルダ名と同じにする（例：sample）。更に「CFBundleIdentifier」を変更する（例：com.mycompany.Syndication.theme.sample）。これがとても重要。
それからもちろんデザインの変更。sample.syndtheme/Contents/Resources の中がテーマのファイル。Articles.css がメインの CSS だ。拡張子 syntmpl の各ファイルで HTML レベルの変更も可能みたいだ。自由度はかなり高い（面倒そうだが）。
これでファイルの配置は完了。最後に Terminal での儀式。

defaults write "com.apple.Syndication" "Theme.ID" "テーマのCFBundleIdentifier"

と打ち込む。さっきの例なら「defaults write "com.apple.Syndication" "Theme.ID" "com.mycompany.Syndication.theme.sample"」となる。Safari を立ち上げ直して feed を開いて確認してみよう。ちなみに元に戻す方法は、Terminal で、

defaults delete "com.apple.Syndication" "Theme.ID"

あまり参考にはならないとは思うけどスクリーンショット（flickr 登録してみました）。

これまで SafariStand が他のプラグインと深刻なコンフリクトを起こすことはなかった。作っている側からすれば奇跡。他のプラグインは一切使っていないので、確認すらせず公開している状態です。
今回ついに WebDevAdditions とコンフリクトしました。同時使用しようとすると Safari 起動時にクラッシュします。ご注意ください。この問題を回避できるかどうかどうかまだわかりません。回避策を探すより機能をパクる方が簡単な気がしないでもない。

Safari 1.3 というか WebKit のすごい隠し機能とは、Web アーカイブのサポートであった。いつものように Safari、WebKit、WebCore を class-dump して、まず検索したのは "Archive"。WebKit に WebArchive というクラスが定義されていて、WebDataSource には - (id)webArchive というメソッドが追加されていた。ありがとう Hyatt。以下サンプル。

#import <objc/objc-runtime.h>
WebView*   webView = 書き出すWebView;
NSString* filepath = 書き出すファイルパス。拡張子は webarchive;
WebDataSource*  dc=[[webView mainFrame]dataSource];
if([dc respondsToSelector:@selector(webArchive)]){
    id webArchive=objc_msgSend(dc,@selector(webArchive));
    if(webArchive){
        [[webArchive data]writeToFile:filepath atomically:YES];
    }
}

こうやって書き出されたファイルを Dock の Safari にドロップ、あるいは Safari のウィンドウにドロップすると見ることができる。アイコンもちゃんと付く。シイラなどの WebKit ブラウザのウインドウにドロップしてもちゃんと表示できる。完全なオフラインモードではないようで、インターネットに繋がっていると、ファイルが更新されているかどうか調べに行くようだ。アーカイブを開いたときの構成ファイルの更新確認は、必ずしも発生するとは限らないようだ。発生することもある、くらいか。キャッシュポリシーによるのかもしれない。よく分からない。
さて、問題はこのファイルが Tiger でも読み込めるかどうか。Developer Seed の Tiger を iMac に入れて試してみたのだが、NDA に抵触する恐れがあるので結果を教えることはできない。2週間待て！

他にも WebView に setEditable:(BOOL) というメソッドが追加されている。Safari でやってみたらみごとに編集できるようになった。だけど専用の UI ではないため編集しにくいし、変更結果を書き出したりキャッシュに反映させたりする方法が分からないので SafariStand での正式な実装は見送った。試してみたい物好きな方は「action_message:HT_toggleWebViewEditable:」というBookmarks Bar Action で setEditable: をトグルできるようにしておいたのでお試しあれ。

Mac OS 10.3.9 Update と共に Safari 1.3 が出てた。数字的には 1.9 くらい付けてもいいんじゃないのと思うくらい変わっていて、 SafariStand 1.2b3 はかなりてこ入れが必要だ。
Safari 1.3 と SafariStand 1.2b3 の組み合わせで把握している不具合

・セパレータが無効になっている（対処）
・gif アニメーションが切れない（対処）
・StandBar のブックマークと履歴が真っ白になる（二回読み込むと表示される。対処）
・ブックマーク追加シートのポップアップメニューの階層化が無効になっている（対処）

他にもあったらコメントよろしく。2ch も随時見てますんで。
それと、すごい隠し機能が組み込んである気がするんで、それも試してみるよ。

今回はやばい。ついにタブが入れ替わる！　Saft のパクリっちゃパクリなんだけど、Saft は Pimp My Safari にあるデモムービー を見るとシイラ風で、対するこっちは OmniWeb 風。まあ、結局パクリなんだがね。
Load Plug-in Manually も派手だ。Flash などをブロックし、配置される場所を矩形で塗って「Plugin - click to load.」と文字を描く。そこをクリックすると読み込みが開始される。これは WebNetscapePluginEmbeddedView に mouseDown: や drawRect: やらを class_addMethods した。また、プラグインを単体で表示させたときは、この view ではなく WebNetscapePluginDocumentView が使われるので、このハックは影響しない。
でもいちばんやばいのは、仕事の締め切りが迫っているのにこんなことをやっていることなのだ（死。

追記
SafariStand Setting... のショートカットを除去しているのは、コンフリクトのテスト用だったのだが、これが原因ではないと分かったので次では元に戻します。
タブ整理は使い勝手よりインパクト、そして実装の簡単さを重視した。シートにしたのは単純に作るのが楽だからという理由。頻繁に使うには手軽ではない。やはりタブラベルをつかんでドラドロするのがいちばん直感的だが、Safari のタブラベルはマウスダウンした時点で切り替わるため、後ろにまわしたまま移動できない（シイラはマウスアップで切り替わる）。この挙動も変えるとなると面倒な予感がするし、どっちにしてもはみ出しているタブは移動できないんですよね。
タブ整理シートを閉じたときにウインドウが揺れるのは仕様です。普通に閉じただけだと、ブックマークバーやタブラベルのロールオーバーがされなくなるので、無理矢理動かしてアップデートさせているというわけです。保存シートではこうはならないので実装の仕方がまずい気がします。

Safari では Google サジェスト で日本語が文字化けしていた（改善されている）。これに限らず Ajax のサンプルで文字化けすることが多い。原因は JavaScript の XMLHttpRequest にある。具体的には、responseText の返り値が文字化けしている。Google サジェスト では XML ではなくただのテキストをやりとりしている。Safari ではデータの内容が XML ではないテキストだと responseText が文字化けしてしまう。この内容が XML であれば化けない。
XMLHttpRequest て名前なんだから XML で渡すべきなのかもしれないが、XML を渡して JavaScript 側でパースするより、扱いやすいデータで渡した方が実装が楽だったり負荷が軽かったりする場合もある。Google サジェスト はスクリプトコードを受け渡していて、そのまま eval しているようだ。
ひさしぶりに WebCore のソースを見る。JavaScriptCore ではなく WebCore の方で実装されていて、ファイルは /khtml/ecma/xmlhttprequest.cpp。エンコーディングに関する箇所に「FIXME」コメントがあるのでここか？　でも XML では化けないから一応ちゃんと設定されてはいるのかな？　ていうか暇が無い。また今度。

ちなみにアマゾン検索サイドバー（日本語が検索できなかったぽいのを修正） は HTML を受け渡しているのだが、この文字化けを回避するために、要素が1個の XML に包んで渡すようにしている。

追記：2005-08-06
Google サジェストは化けなくなってますね。