Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 22/242: « 18 19 20 21 22 23 24 25 26 »

焼畑農業 - Mar 09, 2011

ちょっと本題から外れた所で思う所があったので書く。

知識はとても特殊な資源です。他の資源と違って、知識は複製可能です。他の資源は人にあげると自分の手持ちが減りますが、知識だけは減りません。つまり与えれば与えるほど価値の総和が増えるのです。

エントリ全体として「知識を共有しよう! 知識はギブしても価値は減らないよ! ギブすると価値が増えるよ!」という方向で話が進んでいるのだけれども、しかし、ギブすると知識の価値が減るという面は確かにあるのですよね。

それは、希少性という価値。「情報を持ってる人が、情報を持っていなくて欲している人に対して、対価を取って情報を渡す」という、非対称性を利用して情報格差から金を生む方法が、希少性のない情報に対しては使えなくなってしまう。

わかりやすい例を挙げると、いまどき「いんたーねっとのつかいかた」とか「いーめーるのつかいかた」とか「うぇっぶさーふぃんのやりかた」とかを教えるセミナーを開いた所で儲かりゃせんやろ、って話です。そういう情報がどんどん広まって「当たり前」「知ってて当然」の事になっていく事によって、それを教える事で生計を立てていた人は職を失う訳です。

そういう話があるから、情報をシェアするという事に対して拒否反応を示す人がいるってのは変な話ではないわけですよ。やっぱり。

ただ、情報っていう商材は「いくらでもコピーできる。広まる時はすぐに広まる。生産調整とかそういう事はできない。」という性質があって、希少性だけから金を生もうと思っても、大抵の場合はすぐに儲からなくなっちゃうわけですね。

だから、そんな「情報」という物をそれ自体商材にする事はとっとと諦めて、コピーが効かない別の商材を作るための材料にしちゃいましょうよ、って話だと思うのです。西尾さんのエントリの要点は。

で、そういう材料として使う事を考えた時、情報を集めるだけってのは大抵の場合ほんとそれだけに終わっちゃう事が多い気がする。技術系の話を片っ端からブクマして「後で読む」タグを付けてそれで満足しちゃって、一体何が身についたというのさ?って話ですよ。そんな事やってるより、作ってアウトプットしてを繰り返す中で、コピーの効かない「体験」「経験」を増やしていった方がなんぼかマシなんじゃないの、と僕は思うわけです。

JSDeferredを小さくする - Feb 27, 2011

JSDeferredは非同期処理の制御に特化しててサイズも小さくて素敵な軽量ライブラリだ!と僕は思ってるんだけど、世の中を見回してみると「軽量ライブラリ」って言われてる物は3KB未満とかそういうのが結構あるようだし、jQueryも1.5.1のminified版は28KBって書いてあるし、そうなるとjsdeferred.jsのコメント付き版が0.3.4で19KBというのは「軽量」と呼ぶにはひょっとしてちょっとでかいのかな……という気がしてきた。

なので、JS MinifierとかPackerとかそういう風なやつでどれくらい小さくなるのか実験してみた。

/packer/はそのままだと構文エラーで動かなくなってしまった。}Deferred. って部分が7箇所あってこれがエラーになってるので、全部 };Deferred. に置換(Base62圧縮後だと }4.};4. に置換)したら一応エラーは出なくなった。/packer/の構文解析が貧弱なせいっぽいので、JSDeferredの側で問題になる所にあらかじめセミコロンを入れておけば、この問題は無くなるっぽい気がする。……と書いたからか、ちょよんごさんが対応してくれた。ありがとうございます!

あと、closure-compiler を通すと 2668bytes でした (jsdeferred のレポジトリで rake すると URL が出るようになってます)というアドバイスも頂いたので早速Closure Compilerにかけてみた所確かに小さくなったのですが、シンボル類まで全部失われちゃってこれ単体だと他のスクリプトと組み合わせられないのが残念ですね。(Closure Compilerは他のスクリプトも全部合わせて一緒にコンパイルして使うのが前提ってことなんだろう)

家計簿の記入スタイル - Feb 27, 2011

家計簿の目的は「お金の出入りを記録して、自分が知りたい情報をちゃんと把握できるようにしておく事」ですが、そのためには「全てのお金の出入りをもれなく記録する事」、もっと言うと「ちゃんと記録し続ける事」が大前提になります。どんなに素晴らしい情報を引き出せる家計簿のフォーマットであったとしても、毎回の記入が煩わしいと記入が億劫になって、ちゃんと記録し続けるという事ができなくなってしまう。ちゃんと記録し続ける事を重視するなら、自分が使い続ける上で苦にならない記入フォーマットになってないといけないと思うのです。

かといって、知りたかった情報を引き出せないようでも困ります。僕の場合は「食費」「光熱費」くらいは抜き出して集計できておいて欲しい。でも入力はなるべく簡単にしたい、そうでないと長続きしない。

という事で、だいぶ前にそういうわがままなニーズを満たすための自分用家計簿スプレッドシートをODF形式で作ってみたのですが、この度Googleドキュメントに移行する事にしましたので、Googleドキュメント版のSpreadsheetのテンプレも公開しておきます。

(プレビュー)

どうすれば記入が長続きするだろうか? いっぱいレシートを溜め込んでしまった時でも続けて大量に記入しやすいだろうか? という事を考えて自分はこのスタイルに落ち着きました。分類がドロップダウンメニューではなく自由入力になってるのは、「交際費且つ食費」とかそういうケースに対応したかったのと、キーボードからの連続入力で省入力候補とかのIMEによる入力支援がある状況ならこっちの方が便利なんじゃなかろうか?と思ったのが理由です。

ポイントはG列から右の部分で、「分類」の所にざっくり入力した内容をG列から右の所でIFやら何やらの関数を使って集計して、その上で月ごとの食費等を出すようにしています。「食費」と書いても「食事」と書いても大丈夫なように、分類は文字列の部分一致でマッチするようにしてあって、G列から右の部分をコピペで増やしたり7行目のマッチング対象文字列を書き換えたりすれば、他の分類にも対応できるようになってます。

Windowsの言語バーをIMEがONの時にのみ表示する - Feb 26, 2011

ATOKはATOK2011からWindows XP以降の多言語入力のフレームワークにきちんと則った設計になったとか何とかで、独自のフローティングウィンドウ(ATOKパレット)の代わりに、Windows標準の「言語バー」で全ての操作を行えるようになった。それはいいんだけど、使い勝手がちょっと今までのATOKパレットと違って違和感がある。目下のところ困ってたのは、IMEがOFFの時に言語バーが消えないという事。

というのも、ATOKパレットでは「IMEがONになってる時だけ表示して、IMEを介さない直接入力になってる時は非表示にする」という設定ができたんだけど、フローティング表示にしたWindowsの言語バーにはそういう機能が無いようで、直接入力の時でも常に言語バーが出っぱなしになってしまうのです。

普段の利用とか開発の時とかはそれでも別にいいんだけど、全画面表示でDVDとかBDとかを鑑賞したり、Adobe IllustratorやSAIとかの画面をなるべく広く使いたいアプリケーションを使う時なんかには、これが邪魔になる。

じゃあタスクバーに入れとけばいいじゃんって話なんだけど、タスクバーを縦置きして且つ自動で隠すようにしてる僕の環境では、ぱっとデスクトップの右下に目をやった時にIMEがONなのかそうでないのか(何も出てなければIMEがOFFになってて、ATOKパレットがあればIMEがONになってるってことですね)を判別できないので、そっちの方が不便が大きい。

JustSystem的にはこういう場合は言語バーを非表示にするかタスクバーにドッキングさせた上で従来通りのATOKパレットを使うようにしてくれって事らしい。でもそれも何だか芸がないですよね。できれば新しい物を使いたいし、古いオプションがいつまで残るかなんてわかんないし。乗り換えられるようになったらさっさと乗り換えておいた方がいいという事は、自作アドオンのせいでFirefox 1.5にロックインされてFirefox 2にいつまでも移行できなかった時にも痛感したし。だいたい、従来のATOKパレットではアプリケーションを切り替えたタイミングとかで、切り替え後のウィンドウの方でIMEが無効になってる時でもたまにATOKパレットが出っぱなしになることがあったから、以前のやり方に戻しても万全じゃないのです。

それでもうちょっと検索してみたら、そういう事をはてなで訊いてる人がいて、その回答の中でXLangBarというユーティリティが紹介されてた。昔なつかしVzエディタの作者の方の手による物だそうだ。最終リリースが2006年だったりWindows XP+MS-IME2002専用と書いてあったりで、Windows Vista+ATOK2011な僕の環境では動かないんじゃなかろうかとも思ったんだけど、試してみたらばっちり動いた。多分、Windows標準の言語バーを使ってる物だったら何でも使えるんだと思う。Windowsの多言語入力の仕組みが変わらない限りはしばらくは安心して使い続けられる……かな……?

追記。64bit版のWindows 7で試してみたら、XLangBarは起動するものの、機能しないという結果だった。Windows 7だからアウトなのか64bitだからアウトなのかは不明です。

続きを表示する ...

「T京K芸大学マンガ学科一期生による大学四年間をマンガで棒に振る」を見て自分に重ね合わせて見たり見なかったりした - Feb 19, 2011

うっわーこれほんと他人事と思えないんですけど!!! 僕が2期生として入り卒業した後で学科自体がなくなってしまった大阪電気通信大学メディア情報文化学科の出身としては、こう、なんというか、胸に詰まる物がある。

ただ、僕自身そこまで大学に期待はしてなかったというか、それまでWeb標準がらみのやりとりで、高校生の自分よりその技術の事を知らない大人というのが世の中にいるのか!という事にある意味でショックを受けて、大人に訊けば何でも分かるとか、大学に行きさえすれば何でも教えてもらえるとか、そういう期待はもうできなくなっていたと思うのですよね。

とはいうものの、まだ何を自分が生きていく上での道に選べばいいのかは漠然としていたので、文字通りの人生勉強というか、何かしらの雑学知識が身に着けばいいなというか、自分の知らない世界に触れるきっかけだけでも得られたらいいなというか、そういう事には期待して大学に行ってはいたと思う。会社で毎日PCに向かって仕事してる今では、自分からどんどん動いていかないと新しい物なんて全然目に入ってこないなあ、いざ興味を持って知ろうとしてもどこから取りかかればいいのかさっぱり分からないなあ、という事を時々感じる。それを思えば、いろんなトピックが取り揃えられてて、選んで履修すれば最初の方から順番に教えてもらえる(どこから取りかかればいいのか教えてもらえる)という環境はとても恵まれていたのだなあと、改めて思う。

何度か同じ事を語ってる気がするけど、大学って「めちゃめちゃレベルの高い所に行ってそこでしか教われない事を学ぶ」か「そんなにレベル高くない所に行ってサクッと卒業に必要な単位を取ってあとは無駄に教養を深めたり学外で実践して経験を積んだりする」かのどっちかのスタイルで接するのがいいんじゃないかと思うのですよ。どちらにせよ自分からアグレッシブに動く必要があって、ただイスにボーッと座って話聞いて試験受けてっていうサイクルに乗っかってるだけでは、その時間は果てしなく無駄だろう、と。そんなにレベルの高くない大学で、学内で教われる範囲だけで閉じてるっていうのが、一番駄目なパターンだと思う。

竹熊健太郎氏はこうおっしゃっている。

美大系大学に教える立場でいると痛感するのだが、教育者として作家 志願者に教えられるものは「知識」と「技術(方法論)」の2つしかないということだ。それ以前に「どんな作品を創るか」までは教えようがない。最初に創りたい作品のビジョンがない人は、そういう学校に行くべきではない。less than a minute ago via web

美大でなくてもどこの大学だってそうなんじゃないかと僕は思うんだけど、ビジョンまで持った状態で大学に入ってこれるのが(というかそういう目的意識を持ったから大学に入ろうと思って入るというシナリオが)理想なんだろう。でも僕も含めてほとんどの人は、18歳時点でそんなはっきり人生の目標なんて持ててないんじゃないのかなーって思う。漠然と「高卒じゃ仕事なんてないんじゃないの……?」みたいな不安を持ってて、それでとりあえず大卒っていう資格を取っておきたくて大学に行くんじゃないのかなあ。

ビジョンなんて後から見つければいいじゃん、やってるうちに「これ面白いなあ、これを突き詰めたいなあ」って思ったらそれがその人の道になるんじゃないのかな。というのが僕の考えなので、別にビジョン持ってないからって大学に行ったらあかんとか会社に入ったらあかんとかまでは思わないんですよね。まあ美大だと「おまえそんなヌルい事言っとんちゃうぞコラ!!! 才能ない奴は死んでまえ!!!」くらいのノリになっちゃうのが当たり前なのかもなんですけど。美大の入学式で「この中の99%の人は芽が出ずに消えていきます。ここは、その残り1%の人を見つけて磨き上げるための場所です。」という感じの、お前らのほとんどは捨て駒だ的な演説があったとか無かったとかいう話も、どっかで聞いたか読んだかした気がします。

ともかく、危険なのは「大学に行けば何でもある」って思っちゃう事なんだと思う。大学には何があるのか、っていう事だけじゃなくて、大学には何が無いのか、っていう事も、これから大学に進学しようかという年の子には教えてあげて欲しいものです。……まあ、本当にその事を理解しなければいけない、視野が狭い状態になってる人(過去の僕のような人)ほど、言われてもその言葉の意味などきっと理解できないのでしょうけれどもね。

Excelの「AA」とかのカラム名とカラム番号の数値を相互変換する - Feb 15, 2011

96桁目のセルに所定の値が入ったCSVを作る、みたいな事をやらなきゃいけなくなったんだけど、GnumericにしろExcelにしろカラム名が数字じゃなくてA, B, C, ... Z, AA, AB, ... ZZ, AAA, ...というヘンテコ表記になってるからどこのセルに値を入れればいいかわかんないよウワァァァァン!!!! となったのでJavaScriptで解決した。


var input = prompt('input number or column name');
if (!input) return;

var symbols = 'abcdefghijklmnopqrstuvwxyz';
var result;
if (/^[0-9]+$/.test(input)) {
   input = parseInt(input);
   result = [];
   while (input > 0) {
     result.unshift(symbols.charAt((input - 1) % symbols.length));
     input = Math.floor((input - 1) / symbols.length);
   }
   result = result.join('').toUpperCase();
}
else {
  result = 0;
  input = input.toLowerCase().split('').reverse();
  for (var i = 0, maxi = input.length; i < maxi; i++) {
    result += (symbols.indexOf(input[i]) + 1) * Math.pow(symbols.length, i);
  }
}
alert(result);

カラム名→カラム番号の計算方法は分かったけど、頭が悪い僕にはカラム番号→カラム名の計算式が分からなかったので、検索して出てきたエクセルの1000列目は ALL - つまみ食うのアルゴリズムを丸パクリした。阿呆ですんません……

なんでそこで詰まったかっていうと、単純な26進数の変換ではうまくいかなかったからなんですよね。A==0、B==1という感じで26進数として扱うと、26==Zで27==BAになるんだけど、実際は繰り上がった後はBAじゃなくてAAにならなきゃいけない。そこの所を考慮した計算を多分簡単なループで実現できるとは思ったんだけど、頭が働かなくて無理だった。

Compatibility problem with Tab Mix Plus - Feb 07, 2011

I got a mail from Tab Mix Plus developers team. So I updated compatibility codes in Tree Style Tab for the latest dev-build of TMP. After that I got another mail again, and he said that the latest TST doesn't work with the last public release of TMP. This is the reply:

Hello, onemen.

First, I really think TMP helps very huge people from poor tabbed browsing features of Firefox itself. It is a great thing. So, I hope my addons including TST work with TMP correctly.

However, I'm afraid I can't support both versions of TMP (the latest dev-build and the last public version) anymore, because I believe that they are too different to support simple hacks. I already removed many codes based on the latest dev-build of TMP by this commit, so I can't believe TST works with the last public release only with minor changes only about symbols (function names). And, if I restore codes for old TMP, then both old and latest TMP will override them again and re-introduce many unexpected problems. That is too terrible.

To be honest, it was very painful to read dynamic-eval codes in TMP and TST itself because they are many tree-times eval-ed codes (defined by TMP => overridden by TST => overridden by TMP again). So I don't want to do such a painful work again for the last public release...

Yes, I apologize that I'm also using many eval() to hack TMP. So I believe that both addons TMP and TST should remove all eval-based hacks for each other and make themselves plaggable via their public APIs. TST already defines some public APIs. I agree that they are too less APIs to make compatible TMP with TST now. I'll add new APIs to do it if they are really required for high compatibility. I'll make efforts to keep stable those APIs in future versions. I don't know what APIs are required for TMP, so, I hope to listen your idea.

On the other hand, I hope that TMP provides some public (and stable) APIs for addon developers, like:

  • An API to add extra properties for TabmixSessionData
  • Custom DOM events for TMP specific features

If there is any public document already, could you tell me the URI?

regards,

I can't believe that I keep the current method (eval-based dirty hacks) to make them compatible.

Firefoxでtarget="_blank"なリンクから新しいタブやウィンドウが開かれないようにしたい人向けの話 - Feb 04, 2011

Back to Owner Tab公開したよという話を書いた時にそもそも勝手に新しいタブを開かないようにしたいという意見のトラックバックがあった。そこのコメント欄で「なんでブラウザがそういう機能を提供してくれてないのさ」って議論になってた。

それでふと思い出したんだけど、そういえば昔のMozillaにはtarget属性の指定を無視して現在のタブでリンクを開く機能がなかったっけ? 削除されたのかな? と思って調べてみたら、自分でもすっかり存在を忘れてたけどこの機能はFirefox 4でも健在で、隠し設定としてちゃんと生き残っていた。about:configを開いて「browser.link.open_newwindow」を「1」に変更すれば、target属性によって新しいウィンドウやタブを開くように指定されているリンクでも、普通のリンクと同じように元のページを置き換える形で遷移するようになる。(この機能が入る前に「新しいウィンドウを開くリンク」の挙動を置き換えようとして、旧タブブラウザ拡張では相当な無茶をやっておりました。懐かしい話です。)

実は、Firefoxの設定ダイアログで「新しいウィンドウではなく新しいタブで開く」っていうチェックボックスを切り替えると、この設定の値が「2(新規ウィンドウで開く)」と「3(新規タブで開く)」でトグルするようになってる。「1(現在のタブで開く)」は普通に設定ダイアログを使ってたら選択できないので、about:configか何か別の手段を使わないといけないというわけ。

変更履歴をどんどん遡っていってみたところ、ごく初期の設定ダイアログでは確かに3つの選択肢から1つを選ぶようなUIになってたんだけど、これがFirefox 2でprefwindowベースの設定ダイアログ置き換えられた時に、しれっと「新しいウィンドウで開く」と「新しいタブで開く」の2者択一になってた(現在のタブで開くという選択肢が消えていた)。その時の議論には特に情報はなかったんだけど、「新しいウィンドウで開く」と「新しいタブで開く」の2者択一のUIから今のチェックボックス型UIに変わった時のバグの方を見てみると、まさに前述のエントリで述べられているような議論が繰り広げられていた。

で、ざっと見た感じでは、 「リンクのtarget属性とそれ以外の場合のために2つも設定項目作る意味なくね? 1個でいいんじゃね?」→ 「そもそもなんでUIから1を選択できるようになってないんだ?」→ 「破壊的な挙動になるオプションだから敢えて選択できないようにしたんだよ。」 「そのオプションを選択してたらクラッシュしたこともあったしね。」 「実際、open_newwindow=1に設定するとかなりのWebサイトがぶっ壊れるよ。そりゃウィンドウなんて開くべきじゃないのはみんな分かってるけど、ユーザを混乱させないためにはIEと互換性のある挙動にしとかないと。」→ 「JavaScriptで開かれるウィンドウについてはopen_newwindow=1にしたら色々危ないのは分かるけど、リンクのtarget属性だったら無視しても問題ないでしょ?」→ 「どうしてもアドオン無しでやりたいならこういう方法もあるよ。

という感じで、

  • リンクの場合とJavaScriptの場合で新規ウィンドウ要求をどう扱うかの2つの設定項目は、初心者ユーザの事を優先して1つにまとめることにする。これは譲らない。
  • そうすると、open_newwindow=1にするとWebサイトの動作を壊すなどのトラブルが起こりうる。なので、この値は設定UIには表示しない非推奨の隠し設定のままとする。
  • リンクの場合とJavaScriptの場合で新規ウィンドウ要求をどう扱うかというのを細かく制御したい上級者ユーザは、アドオンを使うなり何なりして対処するように。

という結論に至った……みたいだ。

ということで、すっかり忘れてた&調べ直してて改めて思い出したわけだけれども、browser.link.open_newwindowを1にすると、target属性があるリンクだけでなく、window.open()の読み込み先も現在のタブになってしまうために、親ウィンドウを参照するようなスクリプトが含まれてるページはまともに動かなくなる恐れがあるので、これはお薦めできません。トラブル覚悟でこの設定を使ってもいいけど、target属性があるリンクだけ同じタブで開くようにしたいという場合には、そういう機能を提供するアドオンを使うなり何なりしないといけないよーです。

まあ、いろんな場合に対して細かく挙動を振り分けたいという人は既に(当時の)Mozillaが考える所のメインターゲットではなかったのでした、そういう人は自分がマイノリティであることを自覚してDIYの精神で暮らすしかないですね、という話なのでした。

Bootstrapped Extensionsで設定ダイアログを提供するためのライブラリを作ったよ - Jan 28, 2011

Firefox Developers Conference 2010の時に再起動不要なアドオンの作り方を調べた時、調査の成果を元にJetpack SDKもといAdd-on SDKを使わずにFirefox 3.6とMinefieldの両方に対応したBootstrapped Extensionを作るためのテンプレを作った。それ以後、新しく作るアドオンでBootstrapped Extensionにできそうな物はなるべくそのように開発していこうと思ってて、Back to Owner Tabは実際そうして作ったアドオンの第1号ということになる。

SDKの使い方や仕組みを調べた時にもちょっと思ったんだけど、Back to Owner Tabを作って、「設定ダイアログを持てないのがこんなに辛いとは……」ということを改めて感じた。しかしBootstrapped Extensionで設定ダイアログを提供するのは簡単には実現できなさそうだったので、ずっと諦めてた。

今回、うまく解決できそうな方法をふと思いついて、実際試してみたら案外うまくいったので、テンプレの一部としてライブラリ化してみたBack to Owner Tabの設定ダイアログもこれで提供してる

Bootstrapped Extensionで設定ダイアログを提供するのは難しい

Firefox 2以降ではXULにprefwindowというウィジェットが存在していて、これはFirefox自体の設定ダイアログにも使われている物で、非常に出来がよい。今ある拡張機能の多くも、これを使って設定ダイアログを提供している。

prefwindowができるまでは「設定値を保持して、変更を監視して、変更があったらUIに反映して、ダイアログがキャンセルされたら変更を破棄して……」てな事をいちいち考えてゼロから設定UIを設計しなきゃいけなかったから、非常に辛かった。そういう思いがあるので、Bootstrapped Extensionでも是非これを使いたかったんだけど、Bootstrapped Extensionの「Chrome URLを登録できない」という制限のせいで無理だった。

  • prefwindowも含めて、XULを使うにはChrome URLでFirefoxにファイルを読み込ませないといけない。
    • Minefieldではfile:やresource:で始まるURLでXULを読み込ませても表示されなくなった(リモートXULの廃止)。
  • 仮にXULファイルを読み込ませることができても、表示する文字列をローカライズできない。
    • XULでの多言語対応で欠かせないDTDファイルは、セキュリティの制限によりChrome URLに置かれた物(chrome://foobar/locale/foobar.dtdなど)しか読み込めない。
    • propertiesファイルから文字列を読み込んでJavaScriptで動的に埋め込むということは無理ではなさそうだけど、死ぬ程めんどくさい。XULの「タグで書くだけでいい」「静的なファイルに内容をまとめておける」という利点が完全に死ぬ。

どうしてもやりたければ、XUL以外の方法で頑張って設定UIを作るか、XULで物凄く苦労して作るしか無いってことになって、それはどっちも嫌だった。せっかくprefwindowという素晴らしい物が目の前にあるのに、それを使わないでオレオレUIをゼロから作るなんて、馬鹿馬鹿しくてやってられない。

せめて最新のSDKだったら設定ダイアログを作る機能が入ってたりしないだろうか? あるんならそれを丸パクリできないかな? と思ってたんだけど、SDKに設定ダイアログのためのAPIが入るのはまだ先のことらしいと聞いて、それも諦めざるを得なかった。

それで仕方なく「about:configでカスタマイズしてね」ということにしてたんだけど、まあ普通に考えてこれはエンドユーザ向けとしては酷い話なわけですよ。自分で使う時も、マウス操作だけで設定を変えられないのは困る。

解決の糸口

そんな風に悶々としていて、ふと、「そういえばuserChrome.jsとかではdata: URIでXULドキュメントを動的に作ってたよな」ということに思い至った。試しにdata: URIにprefwindowで作った設定ダイアログの内容を突っ込んでnsIWindowWatcherのopenWindow()でウィンドウとして開いてみたら、少なくともMinefield 4.0b11preでは正常に動いてくれた。data: URIでドキュメントを読み込んだりウィンドウを開いたりする時はオープン元のスクリプトの権限が引き継がれるっぽいので、file: URLでXULを読み込ませた時のような問題も起こらないようだ。

また、E4Xを使えばJavaScriptの中に直接XMLを書けて、しかも属性値にJavaScriptの変数を埋め込める。これなら、propertiesファイルベースでのローカライズでもラベル等を埋め込むのが苦にならない。で、そうして作ったE4XのXMLオブジェクトをtoXMLString()すれば、data: URIで読み込ませるダイアログのためのソースコードが得られる。

ということで、「XULのソースコードを文字列として受け取ってdata: URIにしてウィンドウを開く機能」と「アドオンマネージャでアドオンの設定を開くボタンが押下された時に前述の機能を呼び出す機能」を作れば、Bootstrapped Extensionでもprefwindowベースの設定ダイアログを提供できる事が分かった。

propertiesファイルでローカライズする

propertiesファイルの内容はローカライズ済みの文字列をXULのstringbundle要素を介して取得する方法が一般的だと思うけど、より低レベルな実装のnsIStringBundleServiceを直接呼べば、JavaScriptコードモジュールやBootstrapped Extensionの中からでもpropertiesファイルの中身を簡単に取り出せる。(stringbundle要素はXBLでそういう処理を行うようにしてあるに過ぎない。)

上記のテンプレには、nsIStringBundleServiceをラップしてstringbundle要素と同じインターフェースで使えるようにするライブラリを既に入れてある。

var bundle = require('path/to/lib/locale.js')
               .get('file://.../messages.properties');
var title = bundle.getString('config.title');

という風にすると、ブラウザのUIの言語がjaでmessages.properties.jaというファイルがあればそれが使われて、存在しない場合はmessages.properties.en-US→messages.properties(サフィックス無し)とフォールバックしていく。

Back to Owner Tabに入ってるバージョンのライブラリには含まれてないけど、テンプレのHEADでは resolve('path/to/file') とすると現在のファイルを起点にして相対パスを解決できるようにしてあので、こういう風にも書ける。

var bundle = require('path/to/lib/locale.js')
               .get(resolve('locale/messages.properties'));

なお、Bootstrapped Extensionの場合は読み込んだpropertiesファイルの内容がキャッシュされたままになってしまうとまずいので、shutdown()の時にはnsIStringBundleServiceのflushBundles()というメソッドを呼んで、メモリ上のキャッシュを消すようにする必要がある。このライブラリでもそうしてて、自分でnsIStringBundleServiceを使う時はここに気をつけないといけない。

E4Xで作ったXULコード片から動的にChromeウィンドウを開く

Bootstrapped ExtensionやJavaScriptコードモジュールの名前空間からで既存のDOMWindowを取れない状態でウィンドウを開きたい場合には、nsIWindowWatcherのopenWindow()を使う必要がある。このメソッドに渡すURIとしてdata: URIを指定すれば、その内容のウィンドウがChrome権限で開かれる。

var uri = 'data:application/vnd.mozilla.xul+xml,'
         + source;
Cc['@mozilla.org/embedcomp/window-watcher;1']
  .getService(Ci.nsIWindowWatcher)
  .openWindow(null, uri, '_blank',
              'chrome,titlebar,toolbar,centerscreen',
              null);

ソース文字列の生成は、E4Xを使うと楽にできる。

var xml = <>
      <prefwindow id="backtoowner-config"
                  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
                  title={bundle.getString('title')}>
        <prefpane id="prefpane-general"
                  label={bundle.getString('general')}/>
      </prefwindow>
    </>;
var source = '<?xml version="1.0"?>'
             +'<?xml-stylesheet href="chrome://global/skin/"?>'
             +xml.toXMLString();
source = encodeURIComponent(source);

ラベル文字列等に日本語が入る場合を考慮して、ソース文字列はdata: URIに繋げる前にエスケープしておこう(これをしないと文字化けする)。

基本的にはこれでいいんだけど、実際このまま使うと何となく気持ち悪い。というのも、prefwindowは画面上でのウィンドウの位置や大きさ、最後に選択されていたパネルの名前等をプロファイル内のlocalstore.rdfに自動的に保存するんだけど、この時保存されるデータはウィンドウのURIをキーとして紐付けられているから、data: URIのウィンドウだとlocalstore.rdfが肥大化してしまう。しかも、設定項目を追加したりしてウィンドウの中身が変わるとdata: URIも変わるから、前回情報を保存した時のエントリとは別のエントリが作られてしまって、古いエントリは自動的には消えないから、localstore.rdfが際限なく膨らんでいってしまう事になる。長く使うことを考えたら、これはよくない。

で、何かいい方法はないか考えてみた。

  1. data: URIは必要最小限の長さの固定の物にして、document.write()でウィンドウの中身を動的に書き換える。
  2. data: URIは必要最小限の長さの固定の物にして、DOM操作でウィンドウの中身を動的に書き換える。

nsIWindowWatcherのopenWindow()は開かれたウィンドウのDOMWindowオブジェクトを返す。なので、こんな風にできないかと最初は考えた。

var window = ww.openWindow(...);
window.document
  .open('application/vnd.mozilla.xul+xml');
window.document.write(source);
window.document.close();

が、駄目だった。この方法でドキュメントを書き出すと強制的にHTMLのパーサーが使われてしまうらしく、XULのソースを書き出しても全く動作しない状態になってしまった。

次に、DOM操作でやることを考えた。

XUL Documentの中でRangeを作ってcreateContextualFragment()すると、XULのソース文字列からDOMDocumentFragmentを作ることができる。こうしてルート要素も含めたドキュメント全体を作り直してゴソッと入れ替えたらどうなるだろうか。

var window = ww.openWindow(...);
var range = window.document.createRange();
range.selectNode(window.document.documentElement);
var fragment = range.createContextualFragment(xml.toXMLString());
window.document.replaceChild(fragment, window.document.documentElement);

実際やってみたら、これは期待通りには動いてくれなかった。多分、開かれたウィンドウの内容がまだ完全には読み込まれ切っていない状態でDOM操作を外から無理矢理やろうとしたからなんだろうと思う。

開かれたウィンドウのDOMContentLoadedを待ってからDOMを操作すればprefwindowについてはちゃんと動くみたいなんだけど、dialogとかのもっと汎用的な物も受け付ける事や、ダイアログの中にDOMContentLoadedを待って処理を開始するようなコードを含めたい時に、それでは問題が起こる気がする。

そういうわけで今のバージョンでは、ウィンドウを開く時にnsIVariantの形でソース文字列を渡して、開かれた側のウィンドウの中に1つだけ置いたscript要素でarguments[0]を受け取ってすぐにドキュメントを書き換えるようにしてみている。要点だけ抜き出すとこんな感じ。

var variant = Cc['@mozilla.org/variant;1'].createInstance(Ci.nsIWritableVariant);
variant.setFromVariant(source);

ww.openWindow(
  null,
  'data:application/vnd.mozilla.xul+xml,'
  +encodeURIComponent(
   '<?xml version="1.0"?>\n'
   +'<!-- ' + aURI + ' -->\n'
   +'<?xml-stylesheet href="chrome://global/skin/"?>\n'
   +<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
      <script type="application/javascript"><![CDATA[
        var d = document;
        var e = d.documentElement;
        var r = d.createRange();
        r.selectNode(e);
        d.replaceChild(r.createContextualFragment(arguments[0]), e);
        r.detach();
      ]]></script>
    </window>.toXMLString()
  ),
  '_blank',
  'chrome,titlebar,toolbar,centerscreen',
  variant
);

URIをコメントで埋め込んでるのは、複数のアドオンでこのライブラリを使ってる時に衝突しないようにしたかったから。

実はここに辿り着くまでに結構紆余曲折があった。最初はルート要素を差し替えられるという事に気づいていなかったので、「ルート要素の属性値の情報」と「子孫要素のソース」をそれぞれ取り出してやってみていた。E4Xは実はよく分かってないからちょっと苦労した。

var content = xml.*.toXMLString(); // 子孫要素だけ抽出
var container = xml.copy(); // ルート要素だけ取り出すためにまず一旦全体を複製
var attributes = container[0].attributes(); // ルート要素の属性のリストを取得
var attributesHash = {};
for each (var attribute in attributes) { // 属性名と値のペアのハッシュにする
  let name = attribute.name();
  attributesHash[name] = attribute.toString(); // 属性値はtoString()で取れる
  delete container[0]['@'+name]; // removeAttribute()に相当する操作はこう書く
}
// 子孫要素を削除して、コンテンツ差し替え用のスクリプトに入れ換える
delete container.*;
container.script = <script type="application/javascript">{this._loader}</script>;
container = container.toXMLString();

最初はこれでいいかと思ってたんだけど、コンテンツ差し替え用のスクリプトが走ってる時点で既にprefwindowのXBLのコンストラクタが実行されてしまっていて、複数のprefpaneがあるときの切り替え機能が働いてなかった。

ルート要素をもう一度作りなおしてドキュメントに挿入すればXBLのコンストラクタが実行されるはず、ということでdocument.removeChild(document.documentElement);の後でdocument.appendChild(newRoot);みたいな風な事も試してみたけど、一瞬documentElementが無くなってしまうのがマズいようで、他のどっかの処理がルート要素を参照するタイミングとぶつかってエラーになってしまった。ここはdocument.replaceChild(newRoot, document.documentElement);で一気に差し替えてしまうのが正解だった。昔のGeckoはreplaceChild()でクラッシュする事があったような気がするので無意識に使用をずっと避けてきてたんだけど、Firefox 3.6以降ともなるとさすがに問題なく動いた。

あと、生成した新しいルート要素を挿入しようとするとエラーになる場合もあって、その時は挿入しようとしているノードをdocument.importNode()に1回通してやれば動いた。まあ最終的にはそれ無しで乗り切れたんだけど。

アドオンマネージャからアドオンの設定ダイアログを開こうとした時に、動的に生成したダイアログを開く処理を呼ぶ

これも難儀した。

Firefoxのアドオンマネージャは、install.rdfのoptionsURLに書かれてるURIをwindow.openDialog()で(Mac OS X以外では)モーダルダイアログとして開くようになっている。しかし前述の通りXULの設定ダイアログを読み込ませたかったらChrome URLにしないといけないので、これはそのままは使えない事になる。

とはいえ、optionsURLにはChrome URLしか使えないという話ではない。

最初は、ここに直接javascript:ダイアログを開くためのコードという感じのスクリプトを書く事を考えてみた。でもメタデータの置き場所であるinstall.rdfにそういう実装を含めるのはどうかと思うし、そもそもここにjavascript:スキームを使って書いたスクリプトは普通にコンテンツ領域の権限でしか実行されないようなので、nsIObserverServiceを使ってイベントを発行するとかそういう高度な事は全然できなかった(実際試して無理だった)。

次に、nsIWindowWatcherでの監視とかnsIObserverServiceを介して送られるchrome-document-global-createdとかcontent-document-global-createdとかの通知でもって「あらかじめ登録されていたURI」が読み込まれた事を検知して、その読み込み(ウィンドウのオープン処理)をキャンセルして別の設定ダイアログを開くという事を考えた。

これは結構イイ線まで行ったんだけど、「Firefoxのアドオンマネージャが開いたウィンドウ」が一瞬だけ見えてしまうという点をどうしても回避できなかった。openDialog()の実装を辿ってnsGlobalWindow::OpenDialog()nsGlobalWindow::OpenInternal()nsWindowWatcher::OpenWindowJS()nsWindowWatcher::OpenWindowJSInternal()と掘り返して、何か抜け道はないか探しまくったんだけど、内部で新しいDOMWindowが生成されてウィンドウが実際に画面に出現する事がほとんど確定した後で初めてnsIDocShellのloadURI()にURIが渡されてる(この間URI文字列はC++の普通の変数で引き回されてるだけでJavaScriptの層からは触りようがない)みたいで、ウィンドウがユーザの目に触れる前にどうこうってのは原理的に無理っぽい。

いや、nsIContentPolicyインターフェースを備えたXPCOMコンポーネントを作ってカテゴリマネージャに登録すれば、もしかしたらそこに割り込む事はなんとかできるかもしれない。けど、設定ダイアログ1つ開くためだけにそこまでする元気はなかったし、求める機能に対してコードが膨大になりすぎるから普通にこれはないわーって感じだしで、そういう方向性は最初から切り捨ててる。

結局、すべてのドキュメントの読み込みをchrome-document-global-createdとcontent-document-global-createdの通知で捕捉して、アドオンマネージャのウィンドウが開かれた時にはボタンのクリック操作を監視するイベントリスナを登録し、「設定」ボタンをユーザがクリックした瞬間を捕捉して、登録済みのURIだったらイベントをキャンセルして別のダイアログを開く、という所に落ち着いた。これだとアドオンマネージャの実装(現在どのアドオンが選択されているのか、そのアドオンの設定ダイアログのURIは何なのか、を取得する方法)にべったりになってしまわざるを得ないんだけど、まあその辺のレイヤだったら変更があっても追随するのはそう大変じゃなかろうと思って、妥協する事にした。

まとめ

冒頭に書いたけど、ここまでのまとめがBootstrapped Extensionsテンプレートライブラリとして入ってる。他のファイルの内容に可能な限り依存しないように作ったつもりなので、改造再利用も不可能ではないと思う。実際にどう使うのかというのはBack to Owner Tabでの利用例が参考になるかもしれない(って単にE4XでダイアログをJavaScriptのコードの中に埋め込んでるだけだけど)。

ほんとはFirefox 4に向けて記事を書いていかなきゃいけないんだけど、こういう「あれも駄目でした、これも駄目でした、結局こういう所に落ち着かざるを得ませんでした」という紆余曲折は本に入れてもウケないんじゃないかなーって思ったので、ここに書く事にした。また次に同じような事をしようと思った時に同じ轍を踏まなくてもいいように。技術情報のドキュメントは、未来の自分のために残しておく物なのです。

Page 22/242: « 18 19 20 21 22 23 24 25 26 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき