Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
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の情報の保存と復元の処理は、nsISHistoryの状態の保存と復元が鍵になる。これはFirefox 2のセッション保存機能を実現しているnsSessionStore.jsの中身を見れば理解できるだろう。要約すると、処理の流れは以下のようになる。
- browser要素の
sessionHistoryプロパティ（nsISHistoryのインスタンス）のgetEntryAtIndex()メソッドで、個々のヒストリエントリ（「戻る」「進む」で辿れる個々の履歴）を取得する。 - 個々のエントリのオブジェクト（nsISHEntry/nsIHistoryEntryのインスタンス）の、URIやタイトル、キャッシュのキーなどの情報を取得する。
- 取得した情報を何らかの形で保存する。
- Firefoxを再起動する。
- 保存されていた情報を読み込む。
- 保存されていた情報から、同じ情報を持ったnsISHEntryのインスタンスを生成する。
- browser要素の
sessionHistoryプロパティにnsISHistoryInternalインターフェースでアクセスして、addEntry()メソッドでヒストリエントリとして追加する。
tabbrowser要素に対しては、これをタブの数だけ繰り返せばいい。
Korean Locale - Jan 31, 2007
韓国ではActiveXを使えないブラウザは全然使われてないらしいのにもかかわらず、Split BrowserのKorean Language Packを作って送ってきてくれるという奇特な人がいた。박찬규（sushizang）さん、頑張りすぎです。
ところでKorean Localeって日本語にする時どう表記するべきか悩みますね。北の楽園もとい朝鮮民主主義人民共和国でも使われてる言語だから「韓国語」って言い切っちゃうのも何か変だし、かといってハングルってのはひらがなやカタカナと同じく文字の種類でしかないし。考えるのがめんどいからこのエントリでは「Korean」にしちゃいましたよ。
MozUnitで単体テスト - Jan 22, 2007
MozLabに含まれてる単体テストツールのMozUnitの使いかたが分からない、っていうか真面目にプログラミング勉強したことないから単体テストっていうのがどういう物なのかすらわかってない。説明が全然ないし、普通に他のテスト用のツールを使い慣れた人でないと使えないとかそういう物なのだろうか？
とりあえず試しに動かしてみたけど、何が嬉しいのかいまいち分からない。隠し設定使えば普通にJSコンソールにエラーがリアルタイムで表示されるし、エラー表示だけじゃどこがいけないのか分からないとかいっても結局の所JSデバッガで一行ずつ見ていかないと分からない所だってあるし……自動制御で動かすのも、userChrome.jsとかで自分でスクリプト書いてやるのとの違いが分からない。特に、ブラウザの読み込みが完了したタイミングでのテストとか。
日曜プログラマもどきみたいなのが手を出していい物じゃあないんじゃないのか、これは。
追記。MozUnitのソースコード見てああでもないこうでもないと頭の中で検証してやっと使い方が理解できた。
動画で紹介されてるのは非同期処理の例なんだけど、これで例えばブラウザの読み込みを待ってからテストを実行するとかそういうのをやろうとすると、全然うまくいかない。
こういう場合はコールバック関数とかイベントリスナとかを使って、テストしたい状態になるのを待ってからテストしてやらなきゃいかんのだけど、その方法が全然分からなかった。MozUnitのページには、何やらオプションを指定すると非同期でない（変な日本語だ……）テストができるとか書いてあるんだけど、英語だし略語と技術的専門用語との区別がつかんしで、ちんぷんかんぷんだった。
結論から言うと、async型のテストを作る場合は「setUp」メソッドに渡されるコールバック関数を使うというのが鍵だった。このコールバック関数を実行しないと、処理が一歩も進まない。
Mozilla/Firefoxのターゲッティング - Jan 22, 2007
関西在住のお笑い芸人のカネミノブ氏は、お笑いに専念するために仕事を辞めてショットバーを開き、来る客を相手にネタを見せて練習していたのだそうだ。一般の人にダメ出しをしてもらってネタのクオリティを高めるのが狙いだったのだとか。けれども現実には、「深夜にショットバーに来るような客のセンス」に合わせてネタを作っていたものだから却って一般ウケが悪くなって、前回通った一次予選で今回は落ちてしまった、と。
狙う市場に合わせてネタ作らないとダメだよねっていう話から、Mozilla/Firefoxは日本でどういう地位を築こうとしてるんだろうなあと思った。もし仮に僕が感じてるような利点、無限の拡張性だとかスピーディーな開発が可能な環境だとかそういう所をネタの良さと思ってるんだったら、それは明らかに日本の客層に合ってないよね。
まあシェアを獲得することが「目的」ではないのなら、それでもむしろいいのかなとも思うんだけど。どうせ先行逃げ切りで圧勝した者しか生き残れないこの日本では、今からシェアを奪いに行くなんて土台無理な話っていうか、ねえ……
Split Browser開発のよもやま話（6）：分割されたブラウザの作り込み - Jan 21, 2007
1日目でとりあえず必要最低限の機能は揃ったので、2日目は作り込みのフェーズに入った。
最初の方で作った分割後の領域用のsubbrowserウィジェットは、ブラウザとしてまともな機能が全然無い状態だった。「戻る」や「進む」などのボタンは一応あったけど履歴が何もないときでも常時押せる状態だったし、faviconもページのタイトルも何も表示されないような物。これではさすがに話にならない。
subbrowserの中に何を入れるかなんだけど、今後のことはともかくとして、最初に公開するバージョンでは、「戻る」「進む」「更新」「中止」の4つのボタンと「ロケーションバー」＋「移動」ボタン、「Webサイトのアイコン（favicon）」、読み込み状況を示す「プログレスバー」、それから前のエントリでもチラッと出てきたけど「閉じる」ボタン。これだけ設けておくことにした。
ただ、これだけの要素をあの狭いスペースにそのまま置くとだいぶアレなことになるので、Safariを参考に、「更新」と「中止」のボタン、それから「プログレスバー」と「ロケーションバー」はそれぞれ一つにまとめたんだけど。前者はCSSでの指定、後者はXULのスタックによって実現できた。
Split Browser開発のよもやま話（5）：分割されたブラウザの削除 - Jan 20, 2007
いつまで続くんだこの話。やっと開発一日目最後のところだよ。コード書くのは手っ取り早いけど文章書くのってだりい。ドキュメント整備が遅れるのは世の常ですね。
ええと。とりあえず「分割」する、ブラウザをどんどん増やす方向については前回までのところでできたんで、次は追加したブラウザを削除する方向の処理の話です。
例として、「一回右に分割して、さらにその分割されたブラウザを下に分割する」という場合を想定してみよう。
これはDOM操作的には、hboxにsubbrowser-containerを入れて、さらにその中のvboxにsubbrowser-containerを入れる、という感じになる。タグで書いたらこんな感じだ。
<subbrowser-container>
<vbox>
<hbox>
<box anonid="wrapper">
<tabbrowser/> <!-- 左 -->
</box>
<splitter/>
<subbrowser-container>
<vbox>
<hbox>
<box anonid="wrapper">
<subbrowser/> <!-- 右上 -->
</box>
</hbox>
<splitter/>
<subbrowser-container>
<vbox>
<hbox>
<box anonid="wrapper">
<subbrowser/> <!-- 右下 -->
</box>
</hbox>
</vbox>
</subbrowser-container>
</vbox>
</subbrowser-container>
</hbox>
</vbox>
</subbrowser-container>
右下のブラウザを削除する場合はどうするか？ これは分かりやすい。subbrowserの親の親の親の親にあたるsubbrowser-container要素を削除すればOKだ。また、左の部分、つまり最初からFirefoxにあるブラウザは削除できないので、ここも問題無いといえば問題無い。
難しいのは、右上の位置にあるブラウザ……何らかの子ブラウザを抱えている、中間の階層のブラウザを削除する場合だ。