たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
仕事で書いてるコードがどーにもうまく動かなくて、ついこないだまで正常に動いてたのにどうして?!と思って色々試していたら、特定の関数をtoString()
等で文字列化した時におかしな現象が起こっていた。具体的には、Thunderbird 2.0.0.17のAccountManager.jsで定義されているsaveAccount()
を書き換えようとしたら例外が発生して、onSave()
を文字列にしてreplace()
で改変した物はfor〜inループだった箇所がwhileループになってしまっていた。コードを削っていったらめちゃめちゃ短いコードでも再現したので、Bugzillaに報告しておいた。
上記のような方法で動的にパッチを当てる手法を僕は多用してるので、仕事で書いたコードもここで公開してる拡張機能のコードも、正直、どのくらい影響を受けるのか見当も付かない。早急に解決されることを祈るのみだ。
ちなみにFirefox 3.0.3ではこの問題は起こらなかった。2.0.0.17で入ったセキュリティ上の修正による後退バグっぽい?
追記。29日時点ですでに修正済みだったようだ。これ、あと1ヶ月間放置ですか……? ものっそクリティカルなバグだと思うんだけど。
タイトルは半分くらい釣り。
ごく最近入った変更によって、最後のタブを閉じると常にウィンドウ全体が閉じられる、という挙動になったらしい(Firefox 3.1では多分それがデフォルトになる)。この変更はパッチを書いたDão Gottwald氏ではなく開発責任者の一人のMike Connor氏が決めたものらしい。
この件についてMike Conner氏のマネジメント能力の不足を責めてる人もいるようだけれども、僕としては、この人はUIの設計という物にポリシーを持ってないのかなー、という失望にも似た感想を覚えた。多分SearchLoad Optionsに抱いたものと同じ感覚。
最後のタブを閉じた時にウィンドウも閉じるべきかどうかってのは、隠し設定一つで動作を変えれるような些末な問題に落とし込むべき事じゃなくて、ユーザが触れるフロントエンドとしてのFirefoxの設計思想の根幹に関わる事だと僕は思う。ユーザに「Firefoxとはどういうものか」と説明する時の、メンタルモデルの作り方をガラッと変えてしまうものだと思う。
現状のFirefoxは、「Firefoxというアプリケーションがあって、そのアプリケーションは本体はごくシンプルな機能に限られていて、その中に、タブを伴って複数ページの切り替えができるサブフレームが含まれている」というトップダウンの設計になっている。「タブ」より上位に「メニューバーやツールバーやサイドバー」が存在しており、「タブ」より下位には何も従属していない。こういう構造だからGoogle Chromeのようなマルチプロセスにはできない(するにはとても手間がかかるだろう)。ユーザには、「タブとウィンドウは異なるレイヤに存在するもの」という認識が求められる。
Google Chromeは、「タブという小型でシンプルなWebブラウザがあって、それらを便利に操作できるようにするために一つのウィンドウに押し込めている」というボトムアップの設計になっている(ように見える、そういう演出をしている)。だからマルチプロセスで当たり前だし、「タブ」の上には何も(クローズボックスくらいは付いてるけど、それ以外のタイトルバーすら)なくて、ツールバーもロケーションバーも全部「タブ」より下位の存在として位置づけられている、そういう見た目をしている。ユーザには「タブ」と「ウィンドウ」の違いを意識させないようにしている、ように見える。
ちなみにOperaはMDIのアプリケーションで、この両者の中間にあると思う。「タブ」より上位の物もたくさんあるけど、ロケーションバー等は「タブ」に従属しており下位の存在である、という作りになっている。
タブより上にツールバーがあるか、タブより下にツールバーがあるか、っていうのは、単にバーの置き場所を上下に移動させればいいっていう話じゃないんですよ。フラットな「並び順の問題」じゃなく、縦の「主従関係」なんです、これは。
多分だけど、今回入った変更のような動作が許されるのは、「タブより下にツールバーがあるデザイン」のアプリケーションだけだ。タブより上位に何もないんだから、タブが閉じられたら後には何も残らないのが当たり前だ。
Firefoxの場合はそうではない。タブより外側に沢山の物があって、それらは「自分の下位にタブが存在している」ことを前提に動作している。下位の物(タブ)を一つ消したのなら、それより上位にある物は全部そのままでいるのが当たり前だ。にもかかわらず今回の変更で、下位にあるはずのタブによってそれより上位の物全てが破棄されるようになってしまった。そこにみんなは戸惑っているし怒っているんですよ。そういう、自分の中にある無意識のメンタルモデルまで分かった上で発言してる人は、そう多くないと思うけどさあ。
Mike Conner氏は、そこまでちゃんと分かった上で発言してたのかな? 自分が下した決定が、ユーザの心の中にあるメンタルモデルやそれまで動作していたアプリケーションの設計全ての前提を覆す物だって気がついていたのかな? 多分気付いてないよ。「ちょこっと動作を変えるだけ」そう考えてたんだろう。それが僕には、ポリシーがない無節操な行動に見える。
余談。冒頭で「半分は釣り」と書いたのは、これとは違うレイヤでFirefoxの設計にはポリシーがあるという事も知っているから。彼らは何でもかんでも中に取り込むのではなく、本体はシンプルに保ってそれ以外の要求はアドオンで解決する、というポリシーで開発を行っている(ように見える)。そのポリシーを今後も貫いていて欲しい。ただ、それは「Firefoxというプログラム」の設計ポリシーの話であって、「FirefoxというUI」の設計ポリシーじゃない。それとこれとは問題が別。ここまでタラタラと書いたこと、具体的な「FirefoxというUI」の設計に関して何もポリシーがないと、ユーザや開発者を振り回すことになる。そこのところをどうして彼らは分からないんだろう、という嘆きにも似た感情を、開発者主体で動いているオープンソースのプロジェクトというものについて感じることが僕にはたまにある。
追記。「(過去の)FirefoxとGoogle Chromeの動作(UIの設計思想)のどっちが素晴らしいか」ということについては、僕は考えないことにしてる。どっちにも一長一短がある以上、こういうのは刷り込みと慣れの問題でしかないと思うから。Mac OS伝統の「画面上端にメニューバー」とWindowsやGNOMEやKDEの「ウィンドウごとにメニューバー」のどっちが優れてるのか、というのと似たような話です。あくまで、UIとして(上記のような設計思想・メンタルモデルの面で)一貫性が保たれてないのはそれ以前の問題だ、というのがこのエントリの要旨ってことで。
さらに追記。前の動作に戻す隠し設定が欲しいというバグで中野さんが「初めて最後のタブを閉じようとした時に確認するのがいいんじゃないか」という提案をされている。選択肢をユーザにわざわざ見せるのは良くない、ユーザの理解を妨げる事は徹底して隠すべき、という人もいるだろうし、UIと動作と設計の整合性がとれてるなら僕もそれに同意だけど、現状のUIも動作も設計も全部がバラバラでちぐはぐな状況では、選択を求める方がまだナンボかマシだと僕は思う。ので、賛同コメントを付けてみた。まあ、コード書ける奴が正義のこの世界では、グダグダ評論家じみたことを書き連ねたり嫌味なコメントを残したりするより、とっととパッチ書いてIRCで担当者捕まえてねじ込む方が、実効性は高いと思うんですけどね……
またまた追記。くでんさんのコメントを読んだ後で思ったけど、上で書いた「疑い」とはむしろ逆で、Mike Conner氏は「Google Chromeのようなアプリケーションを元々作りたかったし、その信念に基づいて提案しただけ」なのかもしれないなあ。だから今回の変更も氏にとっては「本来そうあるべき姿に戻そうとしているのだから当然のこと」という感じなのかも。だとしても、できれば、行動を起こす前に「そういう理想はさておき、現状はどうなってるのか?」という所に先に目を向けて欲しかったとは思う。
22日追記。結局、「最後のタブを閉じた時にウィンドウを閉じない」隠し設定を付けるという、件のバグの表題通りの解決策についてはチェックインされて、それで解決ということになったようだ。でもって、他の文句は新しいバグ立てて述べなさいという仲裁も入った。Bugzilla的にはごく自然な流れ。にもかかわらず流れ読まずについ最後っ屁コメントを残してまた議論を蒸し返してしまった僕は、マヌケな悪役もいいとこですね。
SearchLoad Optionsがすでにそういう機能を持っているから。以上。
まあそういう「車輪の再発明はもういいよ(しかも再発明するメリットがないし)」という理由以上に、自分の中では「その機能がヘドが出る程嫌いだから」っていう理由の方が大きいんですけどね。
元々セカンドサーチを作るより前にSearchLoad Optionsの存在を知って、「検索実行後に元の検索エンジンに戻す」という機能のことを知って、心の底から呆れた記憶がある。「ハァ? 何その発想。ありえねえ。理念も実装も全然スマートじゃない。『別の検索エンジンで検索しました。でもその後はその検索エンジンに切り替わったままです。普段使いの検索エンジンに戻ってなくて困ります。』オーケー、ユーザの声としてそういうのがあがってくるのは分かる。でもそこでどうして『じゃあ、検索し終わったら普段使いの検索エンジンに戻しましょう。』って発想になるわけ? そうじゃないだろ。そもそも『一時的に使いたいだけの他の検索エンジンに切り替えて(1)、検索して(2)、検索が終わったら普段使いの検索エンジンに戻す(3)』っていう風にやたらステップが多くてめんどくさい事が問題なわけだろ。その最後の(3)だけ省略できるようにしましたワーイワーイ!って、アホか。もっと頭使えよ。せっかくやるんだったら、その3ステップ全部省略しないと、時間かけて物を作る意味がないだろ。『文字を入力したら検索エンジンの一覧が自動的に出てきて、選択したら即検索される(1)』こうだろJK。その知的怠惰が気にくわない。」という感じである意味怒りに燃えて作ったのが、セカンドサーチなわけです。「これ以上ステップを省略するには脳にプラグ直結する以外無い」ってとこまで突き詰めて考えないと、ダメだと思うんだ、ホントに。
だから、僕がメンテナンスを行っているバージョンにおいては、セカンドサーチにその機能を付ける事はきっとあり得ない。すでに省略され消滅したはずのステップをわざわざ意識しないといけないようにする、なんて選択はよっぽどの事がない限りはしたくない。まあライセンスはMPL/GPL/LGPLなので、フォークしてそういう機能を持ったバージョンを誰かが作る事を止めはしませんけどね。
XUL/Migemo 0.11.1を公開してAMOにアップロードしたら妙に早く承認されて「へえ」と思っていたら、新規インストール時に特に発生する致命的な問題が存在していたことがついさっき判明して、速攻でAMOにログインして当該バージョンを公開停止にしようとしたんだけど、これ今になって気がついたけどファイルの削除はできても特定のバージョンの「公開停止」という措置は取れないんか……公開ページ上の最新バージョンは0.11.1と表示されててダウンロードボタンも緑色なのにクリックするとファイルのダウンロードに失敗する、という妙な状況になってしまった。せめて前のバージョンをダウンロード可能にしてくれればいいのにぃ。
つい先ほど、修正を施した0.11.2をアップロードしたものの、これが公開を承認されるまではずっとこの状態なんだろうか。困った。
しかしまあ何というか、ちゃんとレビューされてなかったのね、ということを今更ながらに実感した次第です。苦笑……できない。
XUL/Migemo新版を公開した。
池田さんに教えてもらうまで存在を知らなかったSearch Markerのような、検索のヒット位置をスクロールバー横に表示する機能を追加した。Search Markerとは以下の点が異なる。
これの絡みで、選択範囲とか強調表示とかまわりの処理をだいぶ書き直した。強調解除で選択範囲が復元されなかったり、強調表示した状態での再検索がやたら重かったり、といった細かい問題が色々直ってるはず。
検索にヒットしてフォーカスされた箇所を画面中央に表示する機能は、以前実装してみたもののいざ使ってみるとウザくて全然使ってなかった。そのウザさの原因はどこにあったのかというと、多分、すぐ次の行とか近くにある語にヒットした時まで強制的に画面がスクロールして、ページのどこが表示されてるのか分からなくなってしまいがちという所だったのだと思う。というわけで、画面の端から30%内側のラインより外にある時だけスクロールするようにした。Safariとかはこういう動作になってたと思う。どうしてFirefoxの素の検索機能はこういう所で気が利いてないんでしょうね。
スクロールといえば、クイックMigemo検索中にページをスクロールしている間はタイムアウトのためのタイマーを止めるようにしてみた。スクロールして眺めてるのにハイライトが消えてしまってムカツク、ということが何度かあったので。
そんな感じの細かい改善が結構入ってます。
んげ。今LDRでふと検索を試してみたら、スクロール全然できなくなった。iframeではないCSSによるスクロール可能なボックスのことを考えるのを忘れていた。
他にもやってる人いそうだなあ……
前のエントリの追記が多くなったので分ける。
「すべて強調表示」の強調箇所がspan要素ではなくnsISelectionになった件については、nsISelectionControllerの選択範囲の型の中にSELECTION_FIND
というのが増えていて、ユーザの選択範囲や検索で現在フォーカスがあたってる箇所を表すSELECTION_NORMAL
とは別に管理されていることが分かった(nsISelectionControllerのメソッドを使うとこれらの型別に選択範囲の一覧を取ることができる)。ということで、「どっちも同じ選択範囲だったらどうやってフォーカス箇所を取ればいいんだ!」という問題は杞憂だったと判明した。
あとはパッチと実際の新しい実装を見ながらFirefox 3.1用のコードを書いて、Safari風強調表示を有効にしてる時だけFirefox 3.0までと同様のspan要素を使うハックを復活させるようにしたところ、アニメーション効果も無事動くようになった。元々、XUL/Migemoでは正規表現にマッチする箇所をまとめて強調しないといけない関係上、span要素を使うハックの処理のほとんどを自前で再実装してたので、思った程には大規模の改修はしなくて済んだ。
一個だけ躓いた所として、XPCOMコンポーネントの新しいメソッドをIDL定義に追加して引数にnsISelectionController型のオブジェクトを渡すようにしていた所、XPIDLでのコンパイルは通るんだけど実際に使う時にNS_ERROR_XPC_CANT_GET_PARAM_IFACE_INFO
というエラーが出てにっちもさっちもいかなくなってしまった。ダメ元で、引数の型をnsISupportsにして受け取り側でQueryInterfaceするようにしてみたところ、ちゃんと動いてくれた。一体何だったんだろうこれは。
textbox要素のsearch型については、パッチを見た限りでは今の所サイドバーの「ブックマーク」と「履歴」でだけ利用されていて、XUL/Migemoのやってるハックには影響しないようだった。
ロケーションバーの方もテストしてみようと思ったらこれが全然動かなくなってて、調べてみたらmozIStorageServiceのopenDatabase()
メソッドでplaces.sqliteを指定して開く所で「ファイルがロックされてるぞゴラァ」と怒られていた。ななななななんてこった!!! SQLite Managerで見ようとしてもやっぱりロックされてて見れないと言われる。どうも不用意な書き換えでデータベースが破壊されないようにロックがかかるようになったようだ。これはやばい。PlacesデータベースにSQLでアクセスできなくなったらXUL/Migemoのロケーションバーまわりの実装の苦労が全て水の泡になる上に、Firefox 3 Hacksで物凄いページ数使って書いた内容がまるっきり無駄になるじゃないか。マジで一瞬気が遠くなった。
精神的に半泣きになりながらmozilla-centralでスマートロケーションバーまわりのコードを調べていたら、いくつかの箇所でDBConnectionとかStorageConnectionとかそういう文字列が登場していて、それをキーに調べてみたらnsPIPlacesDatabaseというインターフェースのDBConnection
プロパティからPlacesデータベースへのコネクションオブジェクトにアクセスすることができるらしいということが分かった。このインターフェースはPlaces API関係のサービスが実装していて、以下のようにすればアクセスできるという事も分かった。
var dbConnection;
if ('nsPIPlacesDatabase' in Ci) { // Firefox 3.1 の場合
dbConnection = Cc['@mozilla.org/browser/nav-history-service;1']
.getService(Ci.nsINavHistoryService)
.QueryInterface(Ci.nsPIPlacesDatabase)
.DBConnection;
}
else { // Firefox 3.0.x の場合
const DirectoryService = Cc['@mozilla.org/file/directory_service;1']
.getService(Ci.nsIProperties);
var file = DirectoryService.get('ProfD', Ci.nsIFile);
file.append('places.sqlite');
if (file.exists()) {
const StorageService = Cc['@mozilla.org/storage/service;1']
.getService(Ci.mozIStorageService);
dbConnection = StorageService.openDatabase(file);
}
}
ホント焦った……4日のトークセッションで土下座せなあかんかと思ったよ。
ちなみにその4日のトークセッションですが引き続き参加者の方絶讃募集中です。9月4日19:00から池袋ジュンク堂にて開催。参加費1000円ワンドリンク制(多分)で定員40名、電話か店頭で申し込む必要があります、としつこく宣伝しておきます。どうかよろしくお願いします!!!!
一旦は実装完了したと思ったんだけど実はまるっきり仕様を読み違えてた事が判明してから直さなきゃと思ってるうちに夏コミがあったりFirefox 3 Hacksの校正があったりですっかり放置してた、Firefox 3.1からの新機能への対応をぼちぼちと。
ていうかこの絞り込み機能、めっさ使いにくい気が……せめて初期状態のキーワードはもうちょっとわかりやすい物にした方がいいと思うんだ。こんなそこいらの使われてない記号を適当に当てはめただけのものなんて、とても憶えられんよ。
しかも複数指定可能とかで頭がこんがらがってきたので、手戻りを防ぐために自動テスト書いたりもしてみた。こういう時ほんとにUxUがあって良かったと思う。
あとlevelさんのエントリの後半で触れられてるスマートキーワードとの連携についても、パッチを見ながら実装してみた。でもこれって実装を見る限りPOSTメソッドのスマートキーワードには非対応ですよねぇ……どうすんだ?
他に、すでに開かれてるタブにマッチした時はどうこうするという話も出てるみたいだけど、僕としては本家の実装が出てきてからその動作を真似る形を取らざるを得ないので、現状は様子見です。
ああ、あとすべて強調表示が選択範囲になったことへの対応もしなきゃなあ。見た目の問題だけじゃなく、今のXUL/Migemoは選択範囲の位置で現在の検索のフォーカスを判断してるから、何もかもが動かなくなる予感。
textboxのsearch型というのは何か影響するんだろうか? 影響有りならこれも対応しないと……
Second Search 0.5.2008090101公開。表題の通り、ロケーションバーから検索できるようにしました。
(スクリーンショット)
ツールバーのカスタマイズでWeb検索バーを外してロケーションバーだけ残している状態だと、ロケーションバーでWeb検索できるようになります。狭い画面を有効活用したい人にオススメ。
将来のFirefoxで検索バーが消滅するかもとどっかで聞いたので「おいおいそれじゃ全然使えなくなっちまうじゃねえか」と思って実装してみたんですが、よく考えたら検索バーが消滅するならこういう機能も標準で付いてしかるべきですよね。ああ無駄な努力。
あと、外観や動作には全く関係ないですが、Firefox 1.5を切り捨てて内部処理を大幅にリファクタリングしました。特にスマートキーワードを検索エンジンとしてリストアップするための機能をだいぶ書き直してます。ブックマークを追加したり削除したりした時の怪しい挙動がだいぶ無くなったと思う。多分。バージョンを0.1上げたのはそれによるところが大きいです。
池袋ジュンク堂にでかフォクすけぬいぐるみが行ってるそうです。9月4日のイベント当日までここにいるそうな。
以下しつこいですが宣伝。Firefox 3 NITEと称して、9月4日19:00から池袋ジュンク堂にてFirefox 3 Hacksの出版記念トークイベントが開催されます。参加費1000円ワンドリンク制で定員40名、電話か店頭で申し込む必要があるとの事です。詳しくはジュンク堂のサイトのイベント案内をご覧下さい。また既報の通り、小サイズのフォクすけぬいぐるみ3体が抽選用景品として提供されたそうなので、ぬいぐるみが欲しい人もおいでませ。
ていうかトークイベントとはいっても何を話題にすればいいのかさっぱりなので、ネタの方も絶賛募集中です。