Latest topics 近況報告

ツリー型タブにアニメーション処理（トゥイーン）を加えつつある - Apr 08, 2009

以前、ツリーの折りたたみでアニメーションするようにしてみた事があった。

この界隈には、GUI要素のアニメーションは嫌いで片っ端から無効にしてて、Web上でもアニメーション効果が使われてると「ウザッ」と思う、というタイプの人が多そうだと思う。でも、アニメーション効果ってのはインターフェースの見た目を考える上で結構バカにできない。

現状のように一気にすべての子タブが出たり消えたりすると、「最初の状態」と「最後の状態」の差が大きすぎて、今自分がどのタブを見ているのか見失ってしまう事がある。でもアニメーションで少しずつ折りたたんだり少しずつ展開したりする事で、「最初の状態」と「最後の状態」の間を段階的に変化させてやると、それほど戸惑わなくて済むようになる。こういう、2つの状態の間を埋めるアニメーションのことを一般にトゥイーンと呼ぶ。使い所を間違えなければ、アニメーションするインターフェースは人にやさしいものとなる。

問題は、再描画が頻繁にかかるのでPCの性能次第では激重になってしまうということ。以前試した時も、自分の環境でとんでもなく重い結果になってしまったので、導入を諦めてた。

で、今日ふと思い立ってもう一度試してみたところ、VistaのAeroが快適に動くような環境ではさすがに快適に動作してくれることが分かった。上記のような小難しい理屈を抜きにしてもヌルヌル動きまくりなのが単純にスゲー面白い。今回はかつて諦めた時のようなフレーム数固定（何回描画したら終わり、というやり方）ではなくフレームレート可変（何秒以内にできる限りの回数だけ描画する、というやり方）で処理するように実装してみたので、貧弱な環境でもそれほど重くはならないと思うんだけど……一応会社のマシンとかで試してみて、問題なさそうなら次版でデフォルト有効にしてみようと思う。

ここでは折りたたみのトゥイーンについてだけ書いてるけど、今回最初に取り組んでたのは元々はインデント幅の変更部分のトゥイーンだった。インデント幅の調整くらいだったらそれほど負荷は高くないだろう、という考えでやり始めたんだけど、最終的には折りたたみまで含めてアニメーション化しても結構気持ちよく動いてくれたということで、上のような話になっている。

面白い副作用として、インデント幅の調整と「折り畳まれたタブを元の状態に戻す」処理とが同時に走ると、まるで画面の左上からその位置にタブが落ちてきて填り込むようなエフェクトになる事に気がついた。どこにタブが増えたかを見失いにくくなる、という効果があるんじゃないかと思う。また、Vista＋Aeroだと割となんでもアニメーションするので、その中に結構馴染んでる気もする。

追記。Let's note W7のUbuntuだと、Shiretokoだとわりかしヌルヌル、Firefox 3.0.xだとフレーム落ちで単純にアニメーションしてないように見えるだけという感じ。ドスパラのWindows XPマシンでも同じような感じだった。コマ落ちした場合でも最低1回は再描画があるので、ワンテンポ遅れる感じはあるんだけど、アニメーションしてる間反応がなくなるという風なことはないので、とりあえず次版から有効にしようと思う。（無効にする設定はもちろん付ける）

Tree Style Tab on Google Chrome - Apr 07, 2009

こんなメールが@google.comなアドレスから来たわけですが。（以下、適当訳は僕による物）

We are working on developing extensions for Chrome and are interested in exploring an opportunity to bring Tree Style Tab to Chrome. The initial design documents may be found here:
今私達はChrome用の拡張機能の開発のために働いており、Tree Style TabをChromeに移植する可能性について関心を持っています。最初の設計書は以下にあります：
http://dev.chromium.org/developers/design-documents/extensions
Further information on the API's that are up for consideration may also specifically be found here:
検討中のAPIについてのさらなる情報はこちら：
http://dev.chromium.org/developers/design-documents/extensions/apis As things further develop, the site will be updated and more information will become available."
将来的に、このサイトは更新され、より多くの情報が利用可能になる予定です。

で、この後にアンケートの案内が続く。アンケートはAPIの案に挙がってる物の中でどれが欲しいかというもので、自由回答欄もあったので、こう答えておいた。

Tree Style Tab totally restructures Firefox's tab bar. If I try to import it to Chrome, I'll need high flexibility not only Greasemonkey-like, but userChrome.js-like to control Chrome's UI from script.
Tree Style TabはFirefoxのタブバーを全体的に再構築します。もしChrome用に移植するなら、Greasemonkey風のものだけでなくuserChrome.js的な、ChromeのUIをスクリプトから制御する高い柔軟性が必要です。

どんなアドオンなのか中身を見ないでとりあえずAMOのおすすめリストから適当に選んでコンタクトしてきてんじゃないか？という気もする（速度重視の設計思想のChromeには、ツリー型タブを移植可能にするような高いカスタマイズ性はそぐわないと思う）。とはいえ、アドオン作者の積極的な取り込みのために動いてるとは、Google本気だな。

とりあえず僕個人に関しては、

• Mozillaに手を出し始めた時、日本語でまともな情報がほとんど無かった。英語ですらも。
• なので、学生としての有り余る時間を投入して、発掘を進める感じで手探りで知識を増やしていった。
• 今から同じことを他のプラットフォームに対してやれる元気がない。（仕事でやることになったら別だろうけど……）
• 天才になれる秘密 - teruyastarはかく語りきでいうところの「凡人」であり、要領よくはやれない。

という感じなので、僕がChromeにツリー型タブを移植するか？というと、可能になったとしてもやらないんじゃないかって気がする。リポジトリは公開してるから、やりたい人はどうぞお好きにってことで……

テキストリンクとpopInとjQuery - Mar 31, 2009

テキストリンクとpopInの競合、について調べてる。

popInが入っているとテキストリンクが動かない、ことの理由はどうも以下の2点によるみたい。

• popInがdblclickイベントをstopPropagation()しているため、テキストリンクにイベントが渡されなくなっている。
• popInがポップアップアイコンの挿入位置を決定するために（？）、選択位置のテキストノードを動的に分割しており、仮にstopPropagation()されない状態にしてテキストリンク側でイベントを拾って処理を行おうとしても、イベント発生時とテキストリンクが処理を行う時とでDOMツリーの構造が微妙に変わっていて、正常に動かない。

何か有効な対策が無いか考えてる。

ところでpopInは内部的にjQueryを使ってるようなんだけど、その旨の表記を僕には見つけられなかった。jQueryはMITライセンスとGPLのデュアルライセンスで、MITを選択した場合でもThe above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.（著作権表示とMITライセンスの許諾表示をソフトウェアの全コピーかもしくは重要な箇所で示す必要がある）ということなので、下手したらMITライセンスの違反ということになるような気が……　（一応フィードバックフォームから送ってはみた）

Mozilla Add-onsのアドオン開発者向けUIがパワーアップしてた - Mar 28, 2009

テキストリンクをThunderbirdにもインストールできるようにしたのにAMOのサイト上ではFirefox専用のままになってしまう件についてボヤいたところ、くでんさんに「Bugzillaで言えばいいじゃない」的な指摘を受けたので、確かにその通りだと思って、念のため新しくバグ報告する前に「target」あたりのキーワードで検索してみたら、Adding new compatible application fails when it's the first oneというバグが出てきて、でもFIXEDになってて「おっかしーなー」と思いながら最初に添付されてたスクリーンショットを見てみたら「Add New Application」と書かれたボタンがあって「なんじゃこりゃあああああこんなん見たこと無いぞおおおお？！」と思って、バグ報告しようとした時に「対象アプリケーション」の英語版表記を知りたくて英語ロケールに切り替えた状態になってたままで開発者用ページのトップに移動したら「新しいUIを試してみよう」みたいな今まで見たことない告知が一番上に表示されてて、そこから辿っていったら今テスト中らしい新UIにアクセスできて（新UIはまだ日本語じゃ利用できないようで、日本語に切り替えてアクセスしようとしたら見れなかった）、それを使うと手動で対象アプリケーションを追加できた。

あと、今までは一度アップロードしたバージョンは、ファイルを削除することはできてもその「バージョン」自体を無かったことにはできなかったんだけど、新UIの方ではそういうファイルが無い状態になったバージョンを「削除」する機能も加わってた。やっときたか……ていうかなんで今までできなかったんだ？

Thunderbird上でテキストリンクを使えるようにしたよ - Mar 27, 2009

テキストリンク バージョン3.1以降で、Thunderbirdでも利用できるようにした。

プレーンテキスト形式のメールでは、Thunderbird自体のURI自動認識の処理を置き換える形で動作する。 Thunderbird本体のURIの認識部分は結構いいかげんなので、地の文とURIが連続してるとたまに酷い事になる。テキストリンク導入後は、Thunderbird自身による抽出結果を一旦全部白紙に戻して、もう一度URIの認識を自力で行うようになる。

同じような事をするアドオンが他にもありそう（っていうかFirefoxではLinkificationがそうだ）だけど、自分では見つけられなかったので……

ところで、AMOの方にもアップロードしたんだけど、過去にFirefox専用として登録したアドオンは後からThunderbirdにも対応した後も、Firefox専用アドオンとして扱われてしまって、Thunderbird Add-onsの方からは辿る事ができないようだ。これってどうにかならんのだろうか。

Mac OS Xのデフォルトテーマに合わせた新スタイルをツリー型タブに加えたよ - Mar 26, 2009

Tree Style Tabで選択可能な組み込みのスタイル指定の一つとして、Mac OS X上のデフォルトテーマ風の物を、cho45さんのStylish用スタイル定義を参考にして作ってみた。 スクリーンショットはVista上での物だけど、OS X上でも確認はしてるのでご安心を。

Firefox 3以前の環境ではcho45さんのスタイル定義ほぼそのまんまを適用するようになってて、その場合はタブの高さが26ピクセル固定になってしまうのでタブの中に何か追加する系のアドオン（具体的にはInformational Tab）との相性が非常に悪い。

で、それをなんとかする方法として、Firefox 3.5以降ではborder-imageが使えるということを思い出したので、その実験というか練習も兼ねて使ってみる事にした。

普通に考えると、tab要素自体に-moz-border-imageを指定すればそれでおしまいという事になるんだけど……ツリー型タブの場合はドロップ位置のマーカーを表示するためにborderを多用してるので、-moz-border-imageをtabに指定すると都合が悪い（普通のborderと同時に指定した場合、-moz-border-imageの方が優先されるようだ）。かといって、内側や外側にもう一つタブ全体を囲うXUL要素を増やそうとすると、他のスタイル指定と激しく競合して見た目がグチャグチャになるし……

で、色々試行錯誤して、Firefox 3以前でタブの右・左・中央のそれぞれに異なる背景画像を表示するために使っていたボックスを流用して解決する方法を思いついた。

この拡大図で言うと、9個に分けられた各領域を普通だったら一つのボックスのborder-imageでカバーするところを、今回は1～3・4～6・7～9の3つのボックスに分けている。-webkit-border-imageや-moz-border-imageの例として紹介されているコードでは4つの辺の幅を同じにしてる例が多いけど、実は4つの辺はそれぞれバラバラに幅を指定できる。なので、

• 図の赤のボックスはurl("共通の画像") 10 10 10 10 / 10px 0 10px 10pxで右の辺の幅を0に。
• 緑のボックスはurl("共通の画像") 10 10 10 10 / 10px 0 10px 0で左右の辺の幅を0に。
• 青のボックスはurl("共通の画像") 10 10 10 10 / 10px 10px 10px 0で左の辺の幅を0に。

という風にしてやる事で、1枚の画像で3つのボックスそれぞれに異なる部分を切り出して適用するような効果を得られる。

また、このままだとタブの高さがborder-imageの幅の分だけ高くなってしまう（border-imageの上辺＋タブのラベルの高さ＋border-imageの下辺＝タブの高さ）ので、タブのラベルやアイコンなどに対して上下にネガティブマージンを設定して、強制的にタブの高さを小さくするようにしてみた。上の図は切り出し位置を示すためにわざと高さを広げた状態だけど、ネガティブマージンを効かせれば、冒頭のスクリーンショットのようなスリムなタブになる。

タブの縦置き、タブのグループ化 - Mar 19, 2009

ツリー型タブに似たアドオン2つを新たに知った。

• VertTabbar
• タブグループマネージャー（TabGroups Manager）

VertTabbarは、タブバーをウィンドウの右または左に移動して縦列タブにするアドオン。Vertigoはずいぶん昔に更新が止まってるようなので、その代替と言えるだろうか。カスタマイズ機能も色々あるみたい。

タブグループマネージャーは、名前から見ても機能的にもTabGroupsの後継っぽい。でも多分中身は全然別物なんだろう。今見てないグループのタブ全部をメモリから追い出して省メモリにする機能とか、検索バーからの検索結果を自動的にグループにする（セカンドサーチとも連携できるらしい）とか、色々高機能だ。

テキストリンクがFirefox 3で速くなった - Mar 17, 2009

テキストリンク 3.0.2009031701で、Firefox 3上では部分的に処理が高速になった。具体的には、Rangeを文字列にする処理がそう。Venkmanでプロファイルを取ってみたらここが滅茶苦茶頻繁に呼ばれてて、ここが遅いと全部が遅くなるという感じで他の部分に影響してたんだけど、nsIDocumentEncoderで代用できる事にやっと気がついた。

nsIDocumentEncoderについては、以前に選択範囲からHTMLのソースを取得する方法を調べてて行き着いたnsISelectionPrivateの実装を見て、存在は知ってた。これを使うことができれば、HTMLを選択してコピー＆テキストエディタにペーストした時のように、BR要素の位置で改行されたりP要素の位置で空行が入ったりSCRIPT要素の内容を除外したりといった、よくある処理が行われた後の整形済みテキストを取得できるんじゃないか、と思って色々試してみたんだけど、その時は、JavaScriptからコンポーネントの機能にアクセスできないようだったので結局諦めてた。でも今日になってふと試してみたら、いつの間にかJavaScriptからもCi.nsIDocumentEncoderが見えるようになってて、これ幸いと使ってみたところかなり期待通りの結果が得られたので、そのまま採用した。

使い方はこんな感じ。

// インスタンスを取得
var encoder = Cc['@mozilla.org/layout/documentEncoder;1?type=text/plain']
               .createInstance(Ci.nsIDocumentEncoder);
// 変換対象のドキュメント、変換先の形式、変換ロジックのフラグを渡して初期化
encoder.init(content.document,
             'text/plain',
             encoder.OutputBodyOnly | encoder.OutputLFLineBreak);
// DOMRangeをセットして……
encoder.setRange(range);
// 文字列に変換する
var result = encoder.encodeToString();

前述した通り、HTML的に非表示になる事が期待されてる要素が除外されたり、画面上の改行位置で文字列の方にも改行文字が入ってくれたりと、単純にDOMRangeのtoString()で文字列化するだけだと問題になる点がこれで一挙に解決される。

JavaScriptから使えるのはGecko 1.9以降のみのようなので、Firefoxの場合は3以降に限定ということになる。Firefoxは2のサポートが切れてるからまあいいんだけど、ThunderbirdはまだGecko 1.8系のままなので、恩恵にあずかれないのが残念だ。

nsIDocumentEncoderを使うようにした副次的なメリットとして、<td>URI1</td><td>URI2</td>のようにセルの間にホワイトスペース文字が無いテーブルでも、nsIDocumentEncoderで文字列化する時はセルの間にタブ文字が入ってくれるため、それぞれ別々のURI文字列として検出できるようになった（最初の段階の「Rangeを文字列化してURIっぽい文字列を正規表現で探す」処理において、それぞれのセルに書かれたURI文字列がちゃんと別々の物としてヒットするようになった）。

追記。3.0.2009031801でさらに高速化した。高速化っていうか、なんていうか……今まで「URIっぽい文字列をマッチング→マッチングしたURIっぽい文字列をページ内検索→ちゃんとしたURIかどうか絞り込み」とやってて、ページ内検索が大量に発生すれば発生する程スピードが遅くなってたんだけど、これを「URIっぽい文字列をマッチング→ちゃんとしたURIかどうか絞り込み→ページ内検索」となるように（ある程度）処理の順番を入れ換えたところ、ページによってはアホかってぐらい速くなった。なんでここに気付かなかったんだろう。マヌケすぎる。

ツリー型タブがおすすめされた結果がご覧の有り様だよ！ - Mar 17, 2009

Mozilla Fluxでとりあげてくれてるけど、ツリー型タブがAMOのスタッフおすすめリストに載った模様です。

ちょっと前にメール来てたけどよく分かんなくて放置してたけど、Mozilla Fluxの記事に色々詳しい情報があったんで「へーそういうことなのかー」と思って統計を見てみたら、ダウンロード数爆増してて吹いた。 前述のメールが来てたのが3月頭で、グラフが飛んでる所がそれ。それまで一日数百件のダウンロードだったのが、10倍くらいに跳ね上がってる。

だからというわけでもないわけでもないんだけど、昨日更新した。久しぶりにAMOの方のレビューを見てみたら「これに対応してくれ」というアドオンの名前がいくつか挙がってたので、それへの対応。あと前回エンバグしてた部分の修正。

FirefoxとSQLとXUL/Migemo - Mar 15, 2009

Firefox 3 Hacks にあるSQLがあまりに長い件 - hogehogeでツッコミを入れられてしまいました……SQLむずい＞＜わけわかんない＞＜

SQLといえば、Firefox 3.5でも機能に影響を与えない範囲で内部的なSQL文がいくつか修正されたそうでるかもしれないそうだ。

• Bug 478097 – Make location bar autocomplete faster
• Bug 479739 – Make location bar autocomplete even faster

でもTrunkにチェックインされたパッチを見ても、どうしてこれで速くなるのか、何が良くなかったのかが、さっぱりわかんない。

XUL/Migemoのロケーションバー周りの機能でもSQLをがんがん使いまくってるけど、Firefox 3 Hacksの件で明らかなように僕のSQL知識不足は深刻なので、きっと物凄いオーバーヘッドがあると思う。誰か改善してくれないかなあー。