Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Split BrowserのAPI - Apr 26, 2007
Split BrowserのAPIのドキュメントを用意してみた。まあ、こんなもん使う人がどれだけいるんだか、はなはだ疑問なんだけど……
拡張性や互換性を高く保つ設計とか - Apr 25, 2007
AiO GesturesとSplit Browserの連携を試みてみよう、と思って挫折した。基本的にSplit Browserは、Firefoxの初期状態の構造であることを前提にして開発されている拡張機能とは、とても相性が悪い。ハック用のコードを書いてみようと思っても、変更箇所が膨大になりすぎて、とてもやる気が起こらない。FireBugとの連携が結局中途半端な状態で止まってしまってるのもそのせいだ。
Split Browserが連携しやすいのは、Firefox全体に渡ってではなく、tabbrowserというウィジェットに対してだけ拡張を行うように設計されている物だ。マルチプルタブハンドラや情報化タブやなんかは最初からそういう風に設計したので、わりかし簡単に連携がとれるようになった。
TBE for Firefox 2に向けて - Apr 25, 2007
こないだ英語で問い合わせを受けた時に書いた物をここにも転載しておく。
I'm going to split TBE and re-create tiny extensions which can work with other extensions together. This is the first step. I repulsed by old TBE because it is too large, too heavy, and too spaghetti...
I've created the extension above at first because the feature is important just for me. "Tab Tree" feature becomes possibly available next. Currently I'm focusing to satisfying myself, not for other users, so I'm very sorry. However I think this is the best way to solve this huge business (restructuring TBE). When I developed the old TBE, I was a school student, and I could work for users (not for me) like a volunteer service. Now I have less time so I believe that the self-satisfaction-driven development is the way.
I'm planning to release a meta package (a new feature from Fx 1.5, which is an archive of several XPIs and can be distributed as one XPI) of those tiny extensions, as new TBE.
一応、こういう事を言いたかったつもりです、という訳。
僕は今、TBEを分割して、他の拡張機能と連係して動作できる小さな拡張機能として作り直そうとしている。これ（マルチプルタブハンドラ）はその最初のステップだ。僕は古いTBEにうんざりさせられてきた。アレは大きすぎて、重すぎて、あまりにスパゲッティ化していた……
僕が前述の拡張機能（マルチプルタブハンドラ）を最初に作ったのは、その機能が他の誰でもなく僕にとって重要だったからだ。多分次は「タブツリー」機能を提供する拡張機能をリリースすると思う。申し訳ないけど、現在、僕は他のユーザのためではなく、あくまで自分自身の要求事項を満足させることだけに集中している。しかし僕はこれが、TBEの再構築という難題を解決するための一番いい方法だと思っている。僕がかつてTBEを開発していた時、僕は学生で、他のユーザのために自分自身の要求以上のクオリティでボランティアのサービス的に尽くしていた。今ぼくはその頃ほど自由時間が無いから、僕は、自己満足ドリブンな開発こそが、唯一の道だと思っている。
僕は今、そうして開発した小さな拡張機能を一つのメタパッケージ（Firefox 1.5以降の新機能で、複数のXPIパッケージを一つのXPIパッケージにまとめて配布できる）にまとめて、新しいTBEとして配布することを考えている。
マルチプルタブハンドラの次にタブツリー機能を提供する物をリリースするつもりだったんだけど、先に実装の簡単な方から片付けることにしたので、上記の発言は結果的には嘘になってしまったなあ……
早速更新したのと、タブの複製で思い付いたこと - Apr 20, 2007
マルチプルタブハンドラを更新する中で、思い付いたというか気がついたことなんだけど。
nsISessionStoreを使ってウィンドウやタブを複製する方法って、うまくやればもっと効率よくやれるんだな。getWindowState()で取得した文字列をそのまま使うんじゃなくて、一旦eval()で評価してオブジェクトの形に戻して、不要なタブのデータとかをあらかじめ全部削除してから、もう一度toSource()でJSON風文字列に戻して使えば、無駄なタブを開く→初期化→無駄なタブを削除 という処理をなくすことができる。
ていうかもっと突き詰めれば、ウィンドウ全体の状態を取得した後で、そのデータの中からある特定のタブの状態だけを抜き出して（それ以外を消して）、そのウィンドウ自身に対してsetWIndowState()で「復元」を実行してやれば、タブをウィンドウ内に複製することだって簡単じゃないか。
というわけで、時々自分自身もタブの複製機能を使っていたこともあって、マルチプルタブハンドラにこの機能を組み込んでみた。
XULとインラインフレームと重ね合わせ - Apr 11, 2007
Split BrowserとGoogle Notebook Extensionがコンフリクトしてるという報告を受けて調べてみた結果のメモ。
XULでは、というかGeckoでは、iframeもbrowserも、インラインフレームについてはCSSのz-indexプロパティの指定とは関係なく、一番最後に描画されたものが一番上に表示されるようになっている。たぶんバグなんだけど、長年そのままになってるから、仕様ということになってるのかもしれない。
Google Notebook Extensionはウィンドウ内にインラインフレームを生成して絶対配置でメインのブラウザ領域の上に重ねて表示してるんだけど、Split Browserで新しいブラウザ領域を追加すると、それがGoogle Notebook Extensionのフレームよりも上に描画されてしまう、というのが問題の現象だ。この問題は分割後の領域でタブを切り替えた際にも発生する。
Google Notebook Extensionのデフォルトの挙動を調べてみると、メインのブラウザ領域については、タブを切り替える度にGoogle Notebook Extensionのフレームを表示し直すようになっていることが分かった。つまりこれと同様に、Split Browserでブラウズ領域を分割した時と、それらの領域内でタブを切り替えたときにも、Google Notebook Extensionのフレームを表示し直してやればいいということになる。
ただ、検証中にさらにもう一つ問題が発覚した。deck要素で内容を切り替えた部分と重なるGoogle Notebook Extensionの領域が白く抜けて描画されてしまうというものだ。deckを使わないようにすればどうにかなりそうなんだけど、そうするとツールバーの高さがガタついてしまうので、どうしたらよいか悩んでいる。
オブジェクト署名済みパッケージの作り方まとめ - Apr 09, 2007
m.tamaki氏によるエントリとFirefox Hacksを見ながら自分でも試してみた。オブジェクト署名証明書が無いので、とりあえずオレオレ証明書での実験だけど。
多数のHTML Canvasを使用する時の、反応速度向上テクニック - Apr 03, 2007
Tab Catalogの一覧表示を開く時にもたつく問題の改善方法を、実験を交えながら改めて検討してみた。
色々試してみて分かったのは、どうもHTML CanvasをDOMツリーに埋め込んだ後、描画されるまでの間がもたついているらしいということ。何も描画していなくても、Canvas要素を埋め込むだけでだいぶ時間がかかるっぽい。
ということでサムネイル用のプレースホルダーだけ用意しておいてCanvas要素をタイマーで一つずつ追加するようにしてみたところ、ホットキーを入力した直後の反応が格段に良くなった。トータルではあまり変わってないか、むしろ遅くなってる可能性もあるけど、体感的にはこっちのほうがずっといい。
nsIContentPolicyによる内部でのリダイレクト - Mar 27, 2007
URNサポートをさらに更新して、今度こそあらゆる場面でちゃんとURNをURLにリダイレクトできるようにした。
何かヒントはないかと思ってbbs2chreaderのb2rThreadRedirector.jsを見たら、nsIContentPolicyの実装？を使って内部的にリダイレクトを行えるようだということが分かった。リダイレクト処理をプロトコルハンドラから分離して同様の実装に移してみたところ、うまくいった。URN用のプロトコルハンドラは現在では、単にurn:というスキーマのURIへのアクセスを受け付けるための役割しか果たしていない。
というわけで、以下、Firefox内部でリダイレクトを行う方法をメモしておこう。
Firefoxで独自プロトコルを定義する方法 - Mar 26, 2007
独自のプロトコルというか独自のスキーマを使えるようにしたくてやり方を調べてみたら、あちこちでAdding a New Protocol to Mozillaという文書が紹介されてたんだけど、日本語訳が無かったのでとりあえず気合いと勘で訳してみた。誤訳があったらゴメンナサイ。
柔軟性の高い開発環境が持つ危険性と、それへの対策 - Mar 24, 2007
プログラムというのはそういうものだで採り上げられているいろんな意味でしゃれにならないApolloという記事は、Firefoxの拡張機能の「危険性」についての話と同じようなことを言っているなと思った。
XPCOMを使えばFirefoxでも確認なしでファイルを削除できる。ファイルの削除時の確認のダイアログは、ExplorerやFinderやNautilusといったシェルが気を利かせて表示してくれているに過ぎない。Windows 98を強制的に再起動させて次の起動時にCドライブをフォーマットする、という拡張機能のサンプルを以前プレゼンで発表したけど、開発環境、特に柔軟性の高い開発環境というのは、そういうこともできてしまう物だということは、理解しておかないといけないんじゃないかと思う。開発者も、利用者も。
携帯でJava製のアプリケーションを実行する時、僕の機種だと、毎回「ネットワークへの接続を許可するか？」と訊ねられる。これは多分パケット通信が発生するから、知らず知らずのうちに大量の通信が発生して料金がヤバいことになるというのを事前に回避するための機構なんだと思うんだけど、こんな風な仕組みを拡張機能やApollo、あるいはOS上で普通に動くアプリケーションに対しても設けていいんじゃないかなー、と思う。
今号のSoftware Designの記事でも書いた、UniversalXPConnect特権を取得するためのコードは、それに近いものがあると思うんだけど、毎回聞かれるか永久に聞かれないかの二者択一というあんまりにあんまりな大雑把さで、ハッキリ言って、実用性の点では激しく疑問だ。Norton Internet Securityを使ってると、アプリケーションの初回起動時や、バイナリが更新されたあとの初回起動時にだけ、そのアプリケーションがインターネットと通信するのを許可するかどうかを訊ねられるんだけど、このくらいの頻度がちょうど良さそうな気がする。
つまり以下のような感じか。
- アプリケーションなり拡張機能なりは、インストーラ内の情報やあるいは実行ファイルのメタデータに、動作するのに必要な特権の一覧を持っている。
- 初回起動時、あるいはファイルが更新されたあとの初回起動時にだけ、それらの特権を付与するかどうかの確認が表示される。
- 特権は、UniversalXPConnectのような「全許可」のようなものではなく、より具体的な、クリティカルな操作に対して個別に用意する。例えば、文字コードの変換やなんかには特権は必要ないだろう。ファイルの読み取り、ファイルの書き込み、インターネットとの通信、パスワードマネージャへのアクセス、Cookieデータベースへのアクセス、他のプロセスの実行、あたりは特権がなければアクセスできないようにしておくべきだろう。
まあ、こんなのただの妄想なんですけどねー。中の人でもなんでもないし、英語もできないし、こんなことBugzillaに提案できやしません……