たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
うあああやっちまった。既にAPI使ってくれてる人がいたにもかかわらずAPIを予告なしに変更するという愚を…… 一応、本家XUL/Migemoと互換のAPI(xulMigemoCore
オブジェクト)も備えていて、そちらは動作を変えないようにしているので、XPCOMを叩かずにそっちを使ってもらっていれば今回の変更の影響は受けなかったと思うんだけど、そんなことを言っても後の祭りというやつで。
なぜこうもグダグダになってしまっているかというと、どうすれば国際化を楽にできるか、サービス同士の絡みを最小限に抑えられるか、という点で自分の中で考えが固まっていなかったからだ。
よりにもよってあの高橋メソッド in XULを、某大学で、講義においてマジメに使ってる人がいるようです。
中国語や韓国語にUIを訳してる人も見掛けた。
XUL/Migemo勝手改造版のXPCOMコンポーネントの機能のうち、日本語の検索に特化した部分とそれ以外とを分割して、国際化というか多言語対応できるようにしてみた。……まぁ、一番メンドクサイ所(入力から正規表現を作る部分)は実質的に日本語専用なので、あんまり意味が無いと言われればその通りなんだけど。
それだけじゃ何なので、おまけとしてやっつけ仕事で英語用のエンジンを作ってみた。「fx a-o」で「Firefox Add-ons」にヒットするようになったりしてちょっと面白いけど、あんまり役に立たないね……
独自エンジンの作り方も書いたので、暇な人が中国語(ピーイン)入力用エンジンとか作ってみてくれることに期待しておきます。
※21日追記。他人(Mozilla)のことには文句言うくせに性凝りもなくAPIをかなり大幅に変更した。誰もまだ手を付けてないことを祈ろう。
※21日追記(2)。APIの使い方とかエンジンの開発の仕方を英訳した。
掲示板で、XUL/Migemo勝手改造版の辞書フォルダの置き場所について相対パスでの指定もできるようにならないか、という要望が出てたのでがんばってみたよ。
以下、解説。
IEでXULを表示する方法というのがあるらしい。IE独自拡張のバインディング?か何かを使えばできるかなあと思ってたけど、ActiveX経由でGeckoをそのまま呼び出すというのは思いつかなかった。まあ普通に考えたらそっちの方が簡単だよね……
XULといえばXULRunner方面は最近はなんだかゴタゴタしてる感じ? Firefox 3はXULRunnerベースに……なんて事をかつては言っていたけれども、現状を見る限りその線はもうなくなったっぽいなあ。
分割ブラウザに、Webページ内のスクリプトから任意の方向に表示領域を分割するAPIを加えた。
今回、最終的に「スクリプトを実行しているページのドキュメントのルート要素に属性値を設定することで挙動を制御する」というあんまりスマートでない仕様に落ち着いたんだけど、これは結構苦肉の策というか、本来やりたかったものとは違う形のソリューションになってしまっている。
そもそもなんでこういう機能(?)を加えたかというと、Stylishという拡張機能の作者さんから「そういうAPIを作ったらどうかね」という意見を頂いたからだ。
拡張機能のビルド用のユーティリティを開発しようとされている方がいる。僕には使いこなせそうもないけど、裾野が広がるという意味でちょっと期待だ。
「たん」が付いてる理由は僕にも分かりません……
タブカタログのサムネイル上でリンクをクリックしたらリンク先に飛べるようにしたついでに、リンク上の中クリックでタブも開けるようにしてみたんだけど、これ、ちょっとでもクリック位置がずれたらタブを閉じてしまいかねないなあ。いまリンクの上にポインタがあるのかどうか一目で分かるようにしたいけど、CSSのcursorみたいなことはJavaScriptじゃ実現できないようなあ……と思った末に、現在ポイントしている位置のクリック可能な要素を強調表示するということを思いついた。でも、これで本当に実用的な速度で動くかどうか?というのははなはだ疑問だった。
GomitaさんのTab Scopeでは、DOM2 Tree Walkerによってすべてのクリック可能な要素を頭から順番に走査していき、要素のボックスの範囲がclickイベントの発生した座標を含んでいるかどうかをチェックする、という手順によってcanvas上のクリック位置に対応するリンクやボタンを見つけている。タブカタログもこの実装をそのまま使わせてもらっている。
この方法の問題は、ページの中にリンクやボタンが大量に配置されていたり、ページの末尾近くまでスクロールしていたりすると、クリック位置の要素を見つけるまでにものすごく時間がかかってしまうという点だ。クリック時のみの処理ならまあ我慢できるかもだけど、mousemoveイベントを拾って「今クリック可能な要素をポイントしている」時だけその事を示そうと思ったら、相当悲惨な事になるのは目に見えている。っていうか実際やってみてあまりの重さに死にかけた。
そこで、何年も前に試して諦めたnsIAccessibleを使う方法に再び挑戦してみることにした。
結論から言うと、これのおかげで現在の位置の要素の取得を飛躍的に高速化できて、やっと実用レベルになったと思う。
拡張機能のファイル群からXPIパッケージを自動的に生成するバッチファイルを、須藤さんの書いたスクリプトとにらめっこしながらシェルスクリプトに移植してみた。
元々バッチファイルもシェルスクリプトもよくわかってなくて、chmodを使う必要があったことからcygwinを入れざるを得なかった関係上、各コマンドの名前がWindows用の物なのかsh用の物なのかよくわかってなかったんだけど、あれこれぐぐりながら情報かき集めて、どうにかこうにか動く物になってくれた。
一応使いかたを説明しておくと、以下のような感じ。
Windowsのエクスプローラでは、ファイルなどのドラッグ中にフォルダの上でしばらく待つと、そのフォルダを勝手に開いてくれる。Firefoxのブックマークのフォルダもそういう風になっている。これと同じように、Second Searchの挙動を変えてみよう、と思って色々実験してみた。