Latest topics 近況報告

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で利用してるアドオン。他に自分で作ったパッチも入れている。

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

「英語（辞書アシスト検索）」モードは、英和辞書で検索する機能ではない - May 28, 2009

ローマ字入力で日本語ページ内の検索を可能にする「XUL/Migemo」拡張 - SourceForge.JP Magazine

さて、もう一つの検索方法である「英語（辞書アシスト検索）」であるが、これは英単語を入力するとその対訳となる日本語の単語が検索されるというモードだ。なぜか筆者の環境ではうまく機能しなかったのだが、一応使い方を説明しておく。

そんな機能実装した覚えないんですけど……

英語モードは、僕が正式にXUL/Migemoを引き継いだ後に行った大改造において、将来的に日本語だけでなく中国語や韓国語などのIMが必要な他の言語に対応できるよう、言語依存の主要モジュールを差し替え可能にした時に、日本語特有の処理（ローマ字入力を平仮名に変換するなどの処理）を含まないプレーンなモジュールの実装例として用意した物だ。

Firefox自身の通常の検索機能と比較して、このモードで具体的に起こる変化としては、「ext」まで入力した時点で「extension」「extend」等の英単語が強調表示されるようになる、という感じなんだけれども……これってぶっちゃけ無意味なんだよね。

• 日本語では、入力した文字列（ローマ字）とページ内のヒット箇所（仮名漢字交じり）の文字列とが一致しない。「kanj」と入力した段階で登録済み単語の「漢字」にヒットしてくれれば、総キータイプ数が少なくなる。→メリットがある！
• 英語では、入力した文字列とページ内のヒット箇所とが原則として一致する。なので、補完が無くても元々キータイプ数は最小で済む。→メリットが無い！

あとは、発音記号付きのアルファベット等を区別せずに検索できるようになるけど、それとて日本語用のエンジンに既に包含されている機能だし。

強いて言えば、日本語とかローマ字とか全然興味がないし必要も無いという英語圏のユーザの人が、Safari風の強調表示だけ利用する時に、ほとんど何も余計なことをしないから邪魔にならない……ということくらいだろうか。英語モードのメリットは。とにかく、「これこれこういう凄いことができるようになる」といった類の意義は皆無だ。そのモードを作った本人が言うんだから、間違いないよ。

マルチプルタブハンドラのAPIを使って貰えて嬉しかったという話 - May 10, 2009

感謝されても喜べないとか書いたけど、マルチプルタブハンドラのAMOでのレビューでAPIのことを誉められたのは、最近あった事の中では特に嬉しいと感じた出来事だ。

マルチプルタブハンドラは「複数のタブをまとめて操作する」機能を提供するアドオンだけれども、公開して多分すぐくらいから「こんな機能も付けてくれ」「あんな機能も付けてくれ」「このアドオンと連携してくれ」とかそんな感じの要望が出たと思う。そうなる事は最初から結構想像できていて、だから、タブの選択状態の制御や選択状態によるタブの取得といった事をできるAPIを開発初期から公開していた。他のアドオン作者の人がこれを見て、マルチプルタブハンドラ用のコードを組み込んでくれたら嬉しいなあ、という風に思っていた。

しかし実際には、MozillaZine Forum（本家の方）で宣伝するわけでもなく、AMOに同じだけの情報を載せられるでもなく、せいぜい分割ブラウザやツリー型タブなどの自作アドオンで細々と使う程度だった。このまま誰にも知られずに終わってしまうんだろうなあ、と思っていた。

なので、Paolo Amadini氏のこのコメントは非常に嬉しかった。

For developers, MTH provides a programming interface that makes it really easy to add new functions that work on multiple tabs; I used this interface in MAF, to provide an easy way to save multiple pages in a single file. （開発者向けに、MTHは複数のタブのために働く新しい機能を非常に簡単に追加できるようにするプログラミングインターフェースを備えている。複数のページを1つのファイルに簡単に保存できる手段を提供するために、私はMAFでこのインターフェースを使った。）

そこに目を付けて貰えた事が嬉しかっただけでなく、MAFという（僕にとっては）ずっと技術的に凄い事をやっているアドオンにマルチプルタブハンドラのためのコードを含めてもらえたということが、嬉しかった。今まで他のアドオンとの連携といえば、ずっとマイナーで世界の隅っこで細々開発してるだけの立場である自分の方から頑張って他のアドオンのコードをなんとか読み解いて連携のためのハックを考える、という事しかやってこなかったので、向こうの方で解決してもらえたということが嬉しかった。

タブキラーをアップデートするついでにFirefox 2以前のサポートを終了した - May 07, 2009

Tab Killer 2.0.2009050701 MinefieldとShiretoko用にアップデートした。

• Firefox 3.5だと「ウィンドウを開き直す」が本体側に装備されているので、Tab Killer側での無理矢理な再現は行わないようにした。
• タブを開く操作が行われた時やタブを閉じる操作が行われた時は、既定の動作として、その要求をどう扱うかを選択するダイアログを表示するようにした。タブを開く要求であれば「今のウィンドウに読み込む」「ウィンドウを開く」「無視する」、タブを閉じる要求であれば「現在のページをアンロード」「ウィンドウを閉じる」「無視する」のそれぞれ3択にした。
• Firefox 2以下を切り捨てた。

こんな物でも要望がたまに来るからFirefoxのユーザ層って趣味の幅が広いなと思う。

Split Browser 0.6.2009050101（Firefox 2以下切り捨て） - May 01, 2009

分割ブラウザ更新した。Firefox 2捨てで、Firefox 3以降専用にした。おかげでJavaScriptコードモジュールとかの便利技術をためらいなく使えるようになった。最近になってアドオンを作り始めた人達がほんと羨ましい。あんな糞みたいな苦労をしなくても遙かに簡単に同じ事ができてより素晴らしい物を作れるんだから。羨ましいを通り越して妬ましくすらある。

更新履歴的には「ShiretokoとMinefieldで動くようにしました」で済ませてるけど、Firefox 2→Firefox 3で色々変わってた部分にかなり見落としがあったのを相当数直してる。ペイン内でのズームとかドラッグ＆ドロップとか。

機能的な変更は以下の点くらい。

• 分割の状態をpreferencesではなくセッションの方に保存するようにした。ウィンドウ単位で状態を保存するので、アドオンインストール後の再起動時やクラッシュからの復帰時はもちろんの事、Firefox 3.5以降の「最近閉じたウィンドウ」でも分割の状態までちゃんと復元されるようになった。
• 閉じたペインを開き直す機能を加えた。デフォルトでは最大10回まで。開き直される位置は元通りではないので注意。
• 分割後の領域のツールバー部分へのドラッグ&ドロップを、タブバーへのドロップと同等に扱うようにした。タブやリンクをツールバー部分にドロップするとタブで開く。

あと、地味にFirefox 3.5以降のプライベートブラウジングに対応してみた。プライバシーついでに、プライバシー情報の消去関係の機能とも統合を図ってる。この辺のノウハウはまたどっかで文書化したい（それか、勉強会のネタにするとか）。

予定もしくは野望もしくは妄想 - Apr 21, 2009

今の所、XUL/Migemoの辞書ファイルは全部普通のテキストファイルなんだけど、これをSQLiteデータベースに置き換えてみようかなと思ってる。メリットがあるのかどうかは分からないんだが。

現在の辞書周りは基本的にはplus7さんが作られた物を踏襲していて、起動時に全ての内容を読み込み、JavaScriptの普通の文字列としてオンメモリで保持しておくようになってる。でもこれだとFennecで動かすのって多分きついだろうなあ、とは思ってた。

どうなんだろう、SQLiteって関係ないデータはメモリに読み込まずにいてくれたりするんだろうか？　Fennecのデフォルト設定を見た限りでは、履歴の保持日数はFirefoxと同じ90～180日となってるから、これを全部メモリ上に読み込んだらエラい事になるよねぇ。と考えると、必要最小限だけメモリに読み込むようになってる事を期待してると考えていいんだろうか？　それとも、これは単にFennec開発陣がSQLiteを過信あるいはモバイルプラットフォームを甘く見てただけで、実は全部オンメモリになっちゃいますとか？

まあとりあえず実装するだけしてみて、それから考えてみよう……

……とりあえずやってみたけど、なんか、めさめさ重い……ちゃんと作ってないから単にどっかで無限ループしてるのかもだけど。しかしそれを抜きにしても、辞書が約4MBだったのがSQLiteにしたら9MBに膨れ上がってしまった。モバイルで使うなんてのはますます非現実的な領域だ。工夫しないと全然お話にならんね……

追記。もうちょっと進めてみたけど、余計泥沼に嵌ってる気がしてきた。バックエンドのSQLite化は無しだな、というのが現時点での結論ですわ。

Tab Mix Plus排斥運動をしたいわけではないんですよ - Apr 21, 2009

Tab Mix Plus は window オブジェクトレイパー - 地獄の猫日記 とか、自分の書いた話がきっかけとなって他の人もTMPの他のアドオンとの互換性に関する話を書いていたりしていて、それらを参照した上で「TMP使うのやめます」と表明している人もいるのですけれども。そこら辺の状況をもって「PiroはTMP批判の世論を作ろうとしているのだ！　扇動しているのだ！　排斥運動をしたがっているのだ！　私怨に狂っているのだ！」とかなんとか言い出すような人が現れたら嫌だなあ、ということで自己保身のために予防線を張っておく。

こんな事言っといてアレですが、僕は今Tab Mix Plusを使ってる人に「今すぐそんな物窓から投げ捨てちまえ！」と言いたい、わけではないんですよ。他のアドオンと組み合わせさえしなければ別に問題はないんだから、使ってて不満を感じてなければ使ってて全然構わないし、使うのをやめる必要もない。

つうかね。グローバルな名前空間がどうこう言い出したら、そもそもFirefox自身のコードだって結構酷いし。将来的に問題が起こりやすい・起こりにくい設計です、ということと、今問題が起こっています・起こっていません、ということはあくまで別の話だし。

単に、いくつもアドオンをとっかえひっかえしながら使うようなスタイルでFirefoxを使うんだったら、「Firefox＋TMP」という環境をベースにするのは、お勧めできないし残念な思いをすることが多そうだよ、って話です。むしろ、「アドオンという仕組みが無かったSleipnir 1.x系のようなブラウザを使ってるのと同じようなもんだ」と思えば、別に何も変じゃないわけです。

他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009

「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。

現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んでいくと、どこかで破綻すると思う。機能の詰め込みは、ある時点までは効率がいいんだけど、ある時点を超えてしまうと、デメリットの方が大きくなってくる。「Piro拡張化」なんて言われるようになる。

作る側の心理として、どうして機能を増やしたくなるのか。他の人はどうか知らないけど、僕はこんな感じだった。

• デバッグより、新機能を実装する方が楽しい。モチベーションが高まる。
• 大は小を兼ねる。大きいことはよいことだ。みたいな。
  • 「こんな小さな物をたくさん作りました」よりも「こんなデカい物をたった一人で作りました」の方がなんかすごそう。
  • より多くの人のニーズを満たせば、より多くの称賛を得られる。誉められて嬉しい。
• それまでに作った部分を土台や部品として使えるので、新しい別個のアドオンにするのに比べてはるかに楽に「すぐ動く物」ができる。
  • 共有できる部分が多ければ、それだけ「無駄が無い」と言える。同じことをするコードが複数のアドオンにあるのは、無駄なことで、気持ち悪いと感じる。
  • 複数の機能を有機的に連携させて、「100％ぴったり、思い通り」の挙動を実現できる。

そんな感じの理由でどんどん機能を加えていく。ある時点までは、それでうまく回る。応援してくれる人とか感謝してくれる人とか、モチベーションを高めてくれる声も寄せられる。でも、なんかの閾値を超えたところで、あらゆる物事が下り坂に転じる。

• 目が行き届かない所が出てくる。
  • 自分が使う物は目が届くけど、使ってない機能には目が届かない。
  • 自分の環境では問題ないのに他の環境では問題が起こる、というケースが頻発するようになる。
• 機能同士が複雑に絡み合っているので、原因の特定がどんどん困難になる。
• 既にある機能との整合性を常に考えないといけないため、新しい機能を加えにくくなってくる。新しい機能を加えることに物凄くエネルギーを使わないといけなくなる。
• 作り込めば作り込む程、前提とする環境への依存が強くなる。
  • 前提がちょっと変わるともう全然動かなくなる。Firefox 1.5向けに作り込んでいたから、もはやFirefox 2に対応できない。
• 最初の頃は「こんなの今まで無かった！　これがあると大違い！　素晴らしい！」と称賛されていたのに、だんだんそれがなくなってくる。
  • 「定番だよね」「むしろ当たり前だよね」と言われるようになってくる。
    • 使う側から見たら「あって当たり前」という感覚だから、感動なんてしない。最初の時点で「とりあえず入れとけ」みたいな感じで勧められるから、それが無い時の不便さも、それを導入することで起こる変化にも、気がつかない。
    • 本当だったら使わなくてもいいはずの人まで、「なんかみんな使ってるみたいだし、入れとくか」という感じで使うようになる。
    • アドオンは薬のようなもので、導入するのは薬効と副作用のトレードオフ。どうしても必要な薬効があるから副作用を我慢して使う、というのが本来そうあるべき使い方なのに、薬効をそもそも知らないまま流されて服用して、副作用に苦しむことになる。
      • 「バグが多い」「不具合ばっかり」「他のアドオンと衝突しまくる」などのデメリットばかりがとりあげられるようになってくる。
    • 「定番なんだから責任持って作れよ」「こんな事もできないの？　定番なんだからできて当然なんじゃないの？」みたいな、お客様気分の声が増えてくる。やる気を削がれてくる。

そんなわけで、精神的な負荷と時間的なコストがどんどん大きくなっていって、タブブラウザ拡張は破綻した。Firefox 1.5のサポート完全終了と共に、過去の遺物となった。

• かといって、Firefox 2デフォルトの状態で我慢できるわけもなくて。
• でも、タブの複数行表示機能をやめてツリー表示しか使わなくなってしまっていた自分には、今更Tab Mix Plusに乗り換えるというのも考えられなかった。
  • 感情的な理由もあった。後から来て追い抜いていった（と同時に、良い評価もかっさらっていった）相手に自分が依存するのは屈辱だと思った。
  • TMPも「Piro拡張化」の行き着く果てまで来ているように思えた。ここから先は下り坂だと思った。

そういうわけで、過去の自分の失敗を徹底的に反省して、ゼロからやり直すことにした。

• 全部詰め込むのはやめる。1つ1つのアドオンを可能な限り単機能に保つようにする。
  • 多少効率が悪くても、重複する部分があっても、個別のアドオンに分ける。
  • 重複する部分がデカくなるようだったら、ライブラリにする。
    • ライブラリはファイル単位で上書きできるようにする。ファイルの中を見て必要な箇所を切り貼りして……という風なことはミスの元になるから、やらない。
    • 複数の異なるバージョンの同じライブラリが同時に入っていても、問題なく動くようにする。
    • という考えで作ったライブラリをリポジトリにまとめてある。
  • 関係ない機能を含めない。コンセプトが合わない機能は、簡単に実装できそうであったとしても、加えない。
    • これはユーザにもメリットがある。
    • 多機能で「とにかく便利」なんてコンセプトだと、ユーザは入れてみるまで薬効と副作用の比較ができない。入れた後も、どれが薬効でどれが副作用なのか分からない。
    • 単機能なら、薬効と副作用を比較しやすい。「この機能はいらないから、入れない」という判断ができる。「よく分からんけどとりあえず入れてみる」という選択を防ぐ圧力が生じる。
      • 多機能にするよりユーザ数は多分減る。でもそれでいい。薬効が必要なくて副作用しか得られない人にまで、使ってもらいたくない。
• 主要な機能を、他のアドオン（自分が作る物も含めて）から使いやすいように「API」として公開する。
  • といっても、物自体は変わらない。あくまでただのメソッド。ただ、作る時の心構えを変える。
    • 自分だけが使うものだから……と思っていると、メンバ変数とかをがんがん使った、実装するのが楽な、結合が密な設計にしてしまいがち。
    • 結合が密だと、100％全ての情報の流れを理解している人間でなければメソッドを使えない。
    • 半年くらいして自分でもすっかり忘れた頃にもう一度見て、すぐに理解できるか？　理解できなさそうなら、それは駄目な設計。
    • 結合をなるべく疎にする。密な結合にしないといけない時は、せめて、情報が双方向に流れないようにする。一方通行に処理を追いかけるだけで理解できるようにする。
  • インターフェースを公開して、ドキュメントも作る。
    • 既に公開してしまっている物だから、安易に変更できないというプレッシャーがかかる。APIの互換性を維持する力が働く。
  • 機能同士の連携は、必ず公開APIを経由して行う。
    • APIでできないことはしない。
    • 必要なら新しいAPIを考える。やっつけ仕事ではなく、ちゃんとした設計で。
• TBEでやってたような、ガチガチの作り込みはしない。
  • 泥臭くてカッコ悪くても、フレキシブルな対応が可能なやり方を取る。
    • XBLでスッキリ書くより、DOMでゴリゴリ書く。
  • なるべく、Firefox自体が持つ構造を壊さない。
    • 要素構造を自分好みにすっかり作り替えてしまえば、自分は楽になる。でも、ユーザが困る。他のアドオン作者も困る。要素構造を変えると他のアドオンと衝突しやすくなる。
  • XBLの使用はできるだけ避ける。
    • 特に、既存のバインディングの「置き換え」は「最後の手段」「禁じ手」と考える。
    • 「まだバインディングが行われていない部分への追加」だったら、使ってもいい。
    • どうしてもXBLじゃなきゃ実現できない、という部分だけに限って使う。それ以外でXBLを使うのは、極論すれば「珍しい技術を使ってる自分」に酔っぱらってる自己満足な行為でしかない、と考える。
  • メソッドを丸ごと置き換える、という事はできる限り避ける。
    • やるのなら、eval()による部分的な書き換えで対処する。
    • やりたいことの大半は、元のメソッドの最初か最後に処理を追加するだけ。メソッドを丸ごと全部別物に置き換えてしまう必要は本来無い。
    • 見通しは悪くなるけど、他のアドオンとの競合は起こりにくくなる。と思う。
    • これによる開発効率・メンテナンス効率の低下は、個々のアドオンを単機能に・シンプルに保つという前提によって相殺する。
• 他のアドオンでできることはしない。
  • 自分一人で抱え込まない。他の人がやってることをわざわざ自分でやり直そうなんてことはしない。
  • 組み合わせて使うことを積極的に推奨する。自分自身も、他のアドオンと組み合わせて使う。
    • 組み合わせて使って問題が起こりにくい設計にしないといけない、という圧力が自然とかかる。

こういう考えに基づいて作ったのが、マルチプルタブハンドラ、情報化タブ、ツリー型タブ、ソース表示タブという4つのアドオンだ。上に書いたことを完全に守れてるとは言えない部分もあるけど、昔に比べれば遙かにマシになってると思う。

作る側としても、使う側としても、僕は今の方がずっと楽だ。

「多機能に」「1つだけで様々なニーズに応えられるように」という方向に頑張ると、縛りがどんどんきつくなってくる。1つのアドオンだけでできることを増やしていこうとすると、妙な話だけど、他のアドオンに頼れなくなっていく。作り込むほどに、そのアドオンを入れた結果が素のFirefoxとかけ離れてしまうから、他のアドオンとの互換性がどんどん失われていく。だから、1つのアドオンだけでしなきゃいけない事がイモヅル式にどんどん増えてくる。

ユーザの視点から見ると、「多機能なアドオン1つだけの世界で完結した使い勝手を享受する」か、「いろんなアドオンを組み合わせて使う」かの、どっちかを選ばないといけないということでもある。両立はできない。

ここで改めて念を押すけれども、僕は、Tab Mix Plusと上記のタブ系アドオンの組み合わせは推奨していない。一応TMPで動くようにはした、けれども、継続的に追っかけ続けるモチベーションが無い。何故なら、僕はTMPユーザではなく、TMPと組み合わせて壊れるようであっても僕自身は全く困らないから。TMPユーザでない他のアドオンの作者の中には、同じように感じてる人もいるんじゃないかと思う。自分が使ってもいないのに対応を迫られるなんて、厄介な奴だ、目障りな奴だ、みたいな。閑話休題。

「多機能なアドオンで、部分的には、痒い所に手が届くような感覚がある。でも、足りない部分もある。それを補うための他のアドオンと組み合わせて使うことは、残念ながらできない。」「単機能のアドオンをたくさん入れていて、それぞれはそれなりに便利。でも、いまいち連携が取れてなくて、痒い所に手が届かない。」そのどっちかを選ばないといけない。

一人あるいは少数の作者の頑張りだけに期待しなきゃいけない、期待して待ってなきゃいけない。多機能長大路線を歩むという事は、ユーザにそれを強いるという事だと思う。僕はそれが嫌になった。

多分、多機能な物を「作る」だけなら、誰にでもできるんだと思う。時間さえかければ。当時の僕にもうなる程の時間があった（大学生で、レベルもそんなに高くなかったから楽に単位を取れて、その分自由に時間を使えた）から、できてたんだと思う。でも、より大きな問題は「作った」の後にあると思う。メンテナンスし続けられるのか？　他のアドオンと協調させられるのか？　多機能長大路線ではそれは難しいと、僕は思った。

ツリー型タブとVimperatorが衝突する - Apr 14, 2009

という報告を受けて調べてみて、解決策が見えなくて頭を抱えてる。

原因はFirefox 3以降でタブの拡張性が深刻なまでに低下したことに起因している。現在、Firefox 3でタブの中に独自の要素（ツリー型タブの「ツリーの開閉状態を示すアイコン」「折り畳まれたタブの数を表示するラベル」など）を追加しようとすると、バインディングを上書きしてやらないといけない。でも複数のアドオンでバインディングを上書き上書きとやってると、最後にバインディングを適用した誰かの物だけが生き残って、他のアドオンが追加したバインディングは全滅してしまう。今回の問題も、ツリー型タブがFirefox自身の提供するバインディングを上書きした後から、Vimperatorがさらにバインディングを上書きしているために、タブの要素構造がツリー型タブが想定する構造から変化して、初期化に失敗するようになってしまっている。

ツリー型タブ、マルチプルタブハンドラ、情報化タブの3つを開発するにあたっては、この問題に対処するために、以下のような方針をとることにした。

• それぞれが別個にバインディングを適用したら、お互いに主導権の奪い合いになる。
  • だから、適用するバインディングは「タブの中に要素を追加できる状態」を整えるためだけの物にする（三者でそれを共有する）。
    • その時の「タブの中に要素を追加できる状態」は、Firefox 2以前のバインディングと互換性がある物にする。
• タブの中への要素の追加は、タブが追加された時のTabOpenイベントを拾って、スクリプトで動的に行う。

これを実現するために作ったのがこちらのライブラリ。3つのファイルで構成されてる。

• tabFx2Compatible.xul
• tabFx2Compatible.xml
• tabFx2Compatible.css

3つを同じ所に置いてXULファイルだけをオーバーレイで読み込ませると、バインディングを上書きする。他のアドオンで同じライブラリが読み込まれてる時は、最新の物が使われる。

これをVimperatorの作者の人にも使ってもらえればいいんだけど……誰にコンタクトすればいいか分からないし、そもそも向こうにはわざわざこれを使う動機がない。Vimperatorユーザは基本的にVimperatorのカスタマイズですべてを解決する傾向にあるようだから、他のアドオンとの互換性が低くても問題にならないだろうし。

ていうか僕自身Vimperator使ってないから、わざわざ上記のような交渉をしようというモチベーションがない。というわけで、上に名前が出てる3つのアドオンのどれかとVimperatorとを共存させたいVimperatorユーザの人は、自分で作者にコンタクト取ってください。（丸投げ）

アニメーション効果を有効にしたツリー型タブの新版とデモ動画を公開したよ - Apr 09, 2009

Tree Style Tab 0.7.2009040901公開した。アニメーション効果の実装の他に、細かいバグ修正も色々。

あと、実際どんな感じかというのをわかりやすく示せるかなと思って、デモ動画も作ってみた。CamStudioもNiVEも使うの久しぶり（っていうかVistaにしてからは初）だから、やり方思い出すのに苦労したよ……

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/M9dUfyoHz3E&hl=ja&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/M9dUfyoHz3E&hl=ja&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

ヌルヌル動いてるのは倍速再生してるわけではなく、これで等倍速です（一応）。タブの影はbox-shadowで描画してるので、Firefox 3.0.xだと影無しになります。

しかしYouTubeはアップロードが簡単になってるわ画質が上がってるわで、いつの間にかすんげーパワーアップしてますね。Stage6とかあった頃とは隔世の感があります。

以下余談。

実装の最後の段階になって困った点として、画面外にタブが開かれた時にそこまで自動スクロールしてくれないという問題が起こってた。スクロールしても、新しく開かれたタブの一個前のタブの位置にスクロールしちゃったりして。上の動画で言うと、0:57あたりで画面下の方でサブツリーを展開した時に、子タブが画面内におさまるように自動でスクロールしてるけど、これがちゃんと動かなくなってた。

なんでこんな問題が起こってたかというと、「そのタブが画面外にあるのかどうかを判定する」「そのタブの位置までスクロールする」といった処理が全部「タブの座標」を基準にしてたせいで、アニメーション開始時点やアニメーション中の中途半端な座標を元に処理を行ってしまい、もうシッチャカメッチャカになってた、という……

上記の処理を行う時に、アニメーション中の座標とアニメーション終了後の座標とのズレをきちんと考慮して計算してやればいいってだけの話なんだけど、普通に考えるとこれがめんどくさい。それぞれのタブがちょっとずつズレて表示されてるわけだから、座標を調べたいタブだけじゃなくてそれより前（上）にあるタブ全部について、そのタブはアニメーション中か？とか、そのタブは非表示か？とかを判別しながらオフセット値を調べないといけないわけで……いちいちそんな計算するのはめんどくさすぎる。メンテナンスし辛そうだし、コードの量が多くなりそうだし、真面目に書く気しないです（大学生の頃だったらやってたかもだけどね……時間は有り余ってたから）。

で、代わりに以下のようなやり方を思いついた。

• アニメーション開始時点やアニメーション実行中は、個々のタブの属性値として本来の座標からのオフセット値を持たせておく。
• タブの座標が必要になった時には、「特定の条件にマッチするタブの当該属性値を収集して合計した値」をXPathで取得して、それを現在の座標に足してやる。

コードにするとこんな感じ。

getYOffsetOfTab : function(aTab)
{
  return document.evaluate(
    'sum((self::* | preceding-sibling::*[not(@tab-collapsed="true")])'+
         '/attribute::tab-y-offset)',
    aTab,
    null,
    XPathResult.NUMBER_TYPE,
    null
  ).numberValue;
},

sum()は、渡されたノードセットの値を数値として合計したものを返すXPathの関数。受け取る結果の型をXPathResult.NUMBER_TYPEと指定すれば、計算結果の数値を直接得られる。XPathはうまく使えばこんな風に、処理対象のノードの絞り込みだけじゃなくその後の処理（ここでは計算）まで一発で済ませられるので面白い。