Latest topics 近況報告

Firefox Developers Conference 2006のプレゼン資料公開しました - Feb 12, 2007

イベント案内のページにプレゼン資料が公開されてるんですが、個別セッションの内容が公開されてないようだったので、ここでも公開することにしました。

Software Designの記事、脱稿しますた - Feb 12, 2007

Software Design次号特集らしい？（今月号の次号予告見ても特に書いてなかったから普通の記事扱いかもしくは再来月かもしれない）　Firefoxの拡張機能作成解説記事の原稿を脱稿した。僕の担当パートはXULとXPCOMの紹介。拡張機能の作成チュートリアルはGomitaさんが書かれるという噂です。

当初は担当箇所は20ページくらいということで話を受けたんだけど、いざネタ出しして書き始めてみたら1/8くらいの時点で既に1万字突破してたりして（1ページ1200字で換算してみよう！）、こりゃいかんということで大幅に内容を削ってみたものの、最終的にやっぱり3万字超……ソースコードの部分も入れると4万5千字近い。もうね、アホかと。ここから先は実際にレイアウトされた後でさらにまたガンガン削っていくしかないようで。

しかしまあ、このペースでこの文字数書けるんだったら、ほんとに単著も夢じゃないかもしれないなと思った。XULの本なんて書いても誰も買わんだろうけどね……

追記：「バカヤロウいくら何でも多すぎだゴラァ（要約）」ということで、流し込み前にサクッと削ることになりそうです。てへ。

さらに追記：資料がないからもう開発したくないという人がいて、開発したいと思う人が少ないから資料書く気にならなくて。

エンティティ参照でモジュール化 - Feb 05, 2007

活用されてる例を知らないんだけど、XULもXMLだから、DTDでエンティティ参照使ってモジュール化できるんですよね。

<?xml version="1.0"?>
<!DOCTYPE page [
  <!ENTITY button  '<button label="button label"/>'>
  <!ENTITY buttons '
    &button;
    &button;
    &button;
    &button;
  '>
]>
<page xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  &buttons;
</page>

実際に見てみる

せっかくだから何かに活用できないものかしらん。

追記。理由は知りませんが、MozillaではChrome URLで示された外部DTDファイルは読み込めません。なので、これはWeb上での話ではなく、拡張機能の開発の話って事で。

Tab Effectのクロスプラットフォームな実装を考えてみる - Feb 02, 2007

Tab EffectはDirectX8以降が必須＝Windowsのみ対応ということなので、環境に依存せず動く物をHTML Canvasを使って作れないかなーと思ってやってみた。

• tabeffectxp.xpi

結論。こりゃとても実用にはならんわ……　行列変換とかやったら死ぬのが目に見えてる（そもそもやり方分からんけど）ので簡単な伸縮だけのエフェクトにしてても、重すぎて重すぎて実用に耐えません。しかも時々ウィンドウの描画に失敗して真っ白になるし。何故？

タブという概念は普通の人（コンピュータの中で何が起こってるのか頭の中で想像することに長けていない人）には分かりにくくて、Tab Effectのようにそれを視覚的に表現する物はユーザビリティの向上において結構役立ちそうな気がするんだけど、ジョークとしか思われなかったりするのが切ないところですね。

追記。Takenさんにアドバイスをもらって、HTML Canvasに描画した物をtoDataURL()で画像としてキャッシュして処理するようにしてみたところ少しだけ軽くなったので、調子に乗ってもうちょっと3Dっぽい効果を加えてみた。

• tabeffectxp-0.2.xpi

軽くなったとはいえ、さすがに台形に画像を拡縮すると重すぎるんで、あくまで「それっぽいニセモノの効果」でしかないですが。

splitterの前後の要素の大きさを変える時の注意 - Feb 02, 2007

もう一つ小ネタ。Split Browserで詰まった箇所。

splitter要素は、ドラッグすると、前後に置かれた要素の大きさを伸縮してくれる。この時、前後の要素の属性一覧とかを見ると、伸縮後の幅（width）もしくは高さ（height）が属性として指定されていることが分かる。

前のエントリに書いたように、「常にツールバーだけは表示される要素」みたいなものをスプリッタの隣に置いておく場合、その要素をツールバーだけの状態に自動で折りたたむ処理は、自分で一から書かないといけない。といってもそんなに難しいことはなくて、要するにツールバーの大きさと同じ値を親要素の大きさに指定してやればいい。

<vbox>
  <hbox id="above" flex="1"/>
  <splitter/>
  <vbox id="below" flex="1">
    <toolbar id="bar"/>
    <hbox id="content" flex="1">
  </vbox>
</vbox>

<script>
  function collapse() {
    var box = document.getElementById('below');
    var bar = document.getElementById('bar');
    box.height = bar.boxObject.height;
  }
</script>

ただ、これには一つ問題がある。折りたたむ方はこれでいいんだけど、元の状態に戻す、つまり畳まれたボックスを広げ直す時には、同じやり方をやっても望んだとおりの大きさにまでボックスが広がってくれないことがある。

これは何故かというと、スプリッタの前後の片方にある要素の大きさを指定し直しても、反対側にあるもう一つの要素の大きさ指定がそのままになっているからだ。畳まれたボックスを狙ったとおりの大きさに広げるには、反対側にある要素のサイズ指定も同時にいじってやらないといけない。

function collapse() {
  var box = document.getElementById('below');
  var bar = document.getElementById('bar');
  box.lastheight = box.boxObject.height;
  box.height = bar.boxObject.height;
}

function expand() {
  var box     = document.getElementById('below');
  var sidebox = document.getElementById('above');
  var last    = box.lastheight;
  var current = box.boxObject.height;
  sidebox.height = sidebox.boxObject.height - (last - current);
  box.height     = last;
}

splitterとgrippy - Feb 02, 2007

Split Browserでも使いまくってるsplitterの注意点。

Mozilla Suiteの頃にはsplitterの中央付近にgrippy（つまみ）が表示されて、それをクリックしたら左右（上下）のどちらかに要素を折りたたむという挙動を示すんだけど、Firefoxの標準テーマではgrippyがdisplay:noneされてるのでぶっちゃけ使えない。拡張機能側のテーマでgrippyの外観を定義するか、grippyに外観が定義されてるテーマを使うかのどっちかをしないと、grippy要素を追加しただけでは何も起こらない。

grippyをクリックした時に前後に折りたためるようにするcollapse属性というのがあるけど、そういう訳なので、実際にはこの機能はFirefoxではほとんど役に立たない。でも、この属性があるかないかでスプリッタの挙動が若干変わるのには注意が必要だ。

例えばこんな場合を想像する。

<vbox>
  <hbox id="above" flex="1"/>
  <splitter/>
  <vbox id="below" flex="1">
    <toolbar/>
    <hbox id="content" flex="1">
  </vbox>
</vbox>

こういう構造の時、スプリッタをドラッグすると、スプリッタの前後にある要素の大きさが無段階で伸縮する。しかし下側のボックスの中にはflex属性が設定されていないtoolbar要素があるので、スプリッタをドラッグしてvbox#belowの大きさを変化させても、実際に伸縮するのはhbox#content（とvbox#below）とhbox#aboveだけになる。結果として、vbox#belowの大きさはtoolbar要素の高さより小さくはならない。toolbarより高さを小さくしようとしても、そこでつっかえてそれ以上スプリッタが動かなくなる。

<vbox>
  <hbox id="above" flex="1"/>
  <splitter collapse="after"/>
  <vbox id="below" flex="1">
    <toolbar/>
    <hbox id="content" flex="1">
  </vbox>
</vbox>

でもこんな風にcollapse属性を指定すると、toolbar要素にflex属性が無くても、つっかえずにスプリッタをボックスの端までドラッグできるようになる。そして端まで達すると下のボックスは折りたたまれて非表示になる。

言い換えれば、スプリッタを動かしても折りたたまれず常に表示されたままになるようなツールバーとかを実装したければ、collapse属性を使わず、常に表示しておきたい要素にflex属性を設定しない、という事でそれを実現できるわけです。

という、小ネタ。

Split Browser開発のよもやま話（9）：ポップアップボタン上へのドラッグ＆ドロップの検知 - Feb 02, 2007

Split Browserの作り込みの話のおまけ。このエントリにはドラッグ＆ドロップの実装に関する話が含まれているかもしれません。

まず基本の話として、Firefoxで（というかXULで）ドラッグ＆ドロップを実装するには、ondraggesutre, ondragover, ondragenter, ondragexit, ondragdropの5つのイベントハンドラと、XPCOMの機能を使う必要がある。このあたりの話はMDCのXULチュートリアルには無いんだけど、古いXULチュートリアルには載ってるので、熟読しとくことをお勧めしたい。

XUL要素をドラッグしようとすると、draggesutreというイベントが発行される。いわゆるAjaxとかだと、ボタンを押下→マウスが動いた、という操作をそれぞれ別のイベントで拾わないといけなかったり、クリック時にマウスがブレただけでドラッグ開始と判断してしまわないように閾値を設定したり、と色々めんどくさい配慮がいるんだけど、XULではdraggestureイベントいっこ拾うだけで済むので話が早い。

ドラッグ中にボタンを放した時、つまりドロップの操作が行われた時には、dragdropというイベントが発生する。これは他のアプリケーションからのドラッグ＆ドロップでも発生するので、アプリケーションの垣根を越えてのデータのやりとりもできる。やろうと思えば多分バイナリデータも渡せるんじゃないかな……やったことは無いけど。

あとの3つのイベントはおまけのようなもので、ドラッグ中にポインタが載った要素に対して、今ドラッグ中のデータをドロップできるかどうか（その要素がそのデータのドロップを受け入れられるかどうか）を示す、とかそういった用途で使うことが多い。

データの受け渡しにはXPCOMの機能を使う。詳細は旧チュートリアルの当該項目で解説されてる……ンだけど、ぶっちゃけこんなの真面目に使ったらあかん（ぉぃ）。これをラッピングして簡単に使えるようにしてくれる物として、nsDragAndDropという標準ライブラリがあって、これはFirefoxでも利用できる（っていうかFirefox内部で使われまくり）ので是非活用しましょう。旧チュートリアルのnsDragAndDropの使い方の解説と利用例は要チェックですよ。

……というのがドラッグ＆ドロップの実装の基本。ここから先は、その応用。

続きを表示する ...

Split Browser開発のよもやま話（8）：ポップアップボタンの実装 - Feb 02, 2007

最初のリリース前の作り込みの話の続き。最終段階、ブラウズ領域の上下左右のポップアップボタンの実装について。このエントリは、XULにおける要素の重ね合わせ表示の方法に関する話が色々含まれています。多分。

実は当初は、こんな機能を付けるつもりは無かった。Split Browserのコンセプト自体が半分冗談みたいなものだったから、そこまで深く考えてなかったし。

ただ、実際に基本的な機能が揃って形になってくると、コンテキストメニューから「ブラウザを分割」を選んでさらにサブメニューから上下左右を選択する、という操作がだんだん鬱陶しくなってきた。と同時に、これをどうにかすることができれば使い勝手の面でブレイクスルーになるのではないか、という事も漠然と思うようになってきた。その最も安直な解決策として思い付いたのが、分割可能な領域の端にポインタが近付いたら勝手にボタンを表示して、それをクリックしたらその方向にそのブラウザを分割する、というものだったワケです。

ただ、思い付いたはいいものの、どうやって実装するかでだいぶあっちに行ったりこっちに行ったりウロウロしてた。

続きを表示する ...

Split Browser開発のよもやま話（7）：状態の保存と復元 - Jan 31, 2007

作り込みのフェーズの続きですよ。だいぶ間が空いてしまったけど。

ブラウザの分割の状態を保存する、と一口に言っても、保存するべき内容は2つのレイヤに分けることができる。

1. それぞれの分割されたブラウザの履歴の状態
2. どの方向にどれだけ分割されているか、という状態

1の情報の保存と復元の処理は、nsISHistoryの状態の保存と復元が鍵になる。これはFirefox 2のセッション保存機能を実現しているnsSessionStore.jsの中身を見れば理解できるだろう。要約すると、処理の流れは以下のようになる。

1. browser要素のsessionHistoryプロパティ（nsISHistoryのインスタンス）のgetEntryAtIndex()メソッドで、個々のヒストリエントリ（「戻る」「進む」で辿れる個々の履歴）を取得する。
2. 個々のエントリのオブジェクト（nsISHEntry/nsIHistoryEntryのインスタンス）の、URIやタイトル、キャッシュのキーなどの情報を取得する。
3. 取得した情報を何らかの形で保存する。
4. Firefoxを再起動する。
5. 保存されていた情報を読み込む。
6. 保存されていた情報から、同じ情報を持ったnsISHEntryのインスタンスを生成する。
7. browser要素のsessionHistoryプロパティにnsISHistoryInternalインターフェースでアクセスして、addEntry()メソッドでヒストリエントリとして追加する。

tabbrowser要素に対しては、これをタブの数だけ繰り返せばいい。

続きを表示する ...

MozUnitで単体テスト - Jan 22, 2007

MozLabに含まれてる単体テストツールのMozUnitの使いかたが分からない、っていうか真面目にプログラミング勉強したことないから単体テストっていうのがどういう物なのかすらわかってない。説明が全然ないし、普通に他のテスト用のツールを使い慣れた人でないと使えないとかそういう物なのだろうか？

とりあえず試しに動かしてみたけど、何が嬉しいのかいまいち分からない。隠し設定使えば普通にJSコンソールにエラーがリアルタイムで表示されるし、エラー表示だけじゃどこがいけないのか分からないとかいっても結局の所JSデバッガで一行ずつ見ていかないと分からない所だってあるし……自動制御で動かすのも、userChrome.jsとかで自分でスクリプト書いてやるのとの違いが分からない。特に、ブラウザの読み込みが完了したタイミングでのテストとか。

日曜プログラマもどきみたいなのが手を出していい物じゃあないんじゃないのか、これは。

追記。MozUnitのソースコード見てああでもないこうでもないと頭の中で検証してやっと使い方が理解できた。

動画で紹介されてるのは非同期処理の例なんだけど、これで例えばブラウザの読み込みを待ってからテストを実行するとかそういうのをやろうとすると、全然うまくいかない。

こういう場合はコールバック関数とかイベントリスナとかを使って、テストしたい状態になるのを待ってからテストしてやらなきゃいかんのだけど、その方法が全然分からなかった。MozUnitのページには、何やらオプションを指定すると非同期でない（変な日本語だ……）テストができるとか書いてあるんだけど、英語だし略語と技術的専門用語との区別がつかんしで、ちんぷんかんぷんだった。

結論から言うと、async型のテストを作る場合は「setUp」メソッドに渡されるコールバック関数を使うというのが鍵だった。このコールバック関数を実行しないと、処理が一歩も進まない。

続きを表示する ...