2009-03-02
Thunderbird 3 Beta 2を導入してみた
これまでは様子を見ていたが、ようやくThunderbird 3にWebメールの管理を任せてみようと思い立った。levelさんはα版の時代から「個人環境で使用しています」とおっしゃっているが、筆者はまだ全面的に移行するだけの度胸がない。ときどきバックアップを取っているとはいえ、メインアカウントのメールをβ版のソフトで行うのは、リスクを考えて躊躇する。そこでWebメールの出番となった。
アカウント設定
Thunderbird 3 Beta 2をインストールして起動すると、アカウントウィザードが表示される。「Gmail IMAP」が項目にあるので、これを選択し、ユーザー名、メールアドレス、Gmailのパスワードを入力すれば完了だ。わずかそれだけで、受信トレイにずらりとメールが並ぶ。後で調べてわかったのだが、一般的な手順としては、まずWebブラウザでGmailにログインし、IMAPを有効にすることになっていた。だが、筆者はその操作を省いても、IMAPで接続できた。これはGmailのデフォルトが変わったのか、それともThunderbirdが自動で設定してくれたのだろうか。
一方、Hotmailのアカウントは、これほど簡単にはいかなかった。ツールメニューの「アカウント設定」から、「アカウントを追加」をクリックして、自分でサーバーの設定をしないといけない。HotmailはIMAPに未対応なので、必然的にプロトコルはPOP3になる。受信サーバーと送信サーバーの情報を調べて入力するのは、少し骨が折れた。
受信サーバー
受信サーバーは、サーバー名を「pop3.live.com」とし、ポート番号を「995」に指定。セキュリティ設定は接続の保護を「SSL/TSL」にする。これらの情報をアカウントウィザードに入力するだけで済めばよかったのだが、そうした設計にはなっておらず、いったんウィザードを終了した後で、アカウント名の「サーバ設定」を呼び出す必要がある。
送信サーバー
送信サーバーは、「送信（SMTP）サーバ」という項目が独立して用意されているので、そこに情報を入力する。先にGmailを設定したことで、Hotmailの送信サーバーがGmailのものになっているので、新たに追加し、さらにHotmailのアカウント設定に戻って、正しく送信サーバーが指定されているか確認する。
具体的には、サーバー名を「smtp.live.com」とし、ポート番号を「587」に指定。「セキュリティと認証」欄で「ユーザ名とパスワードを利用する」にチェックを入れて、ユーザー名としてHotmailのアドレスを入力する。接続の保護は「STARTTLS」に。
使用感は？
起動もその後も動作も、Thunderbird 2より確実に速い。Thunderbird 3は、Beta 1からGecko 1.9.1ベースに移行しており、その効果が現れている。枯れたGecko 1.9.0.xを使えば開発は容易になったと思われるが、あえて開発版のエンジンを採用し、最新の技術を取り入れることにした*1。RSSリーダーとしてThunderbird 3を使うユーザーには、とくに影響が大きいのではないか。
ユーザーインターフェイス（UI）は、Thunderbird 2とあまり差がない。目に付く違いは、メールのヘッダ領域の表示と、タブだ。
ヘッダ領域には、「返信」「転送」「アーカイブ」「迷惑メールとしてマーク」のボタンと、削除を示すゴミ箱のアイコンボタンが並んでいる。メールの処理に関するコントロールは本文の近くに置くべきとのポリシーから、こうなっている。慣れのせいで、使っているとどうしてもツールバーに目がいってしまうが、Beta 3ではツールバーもリニューアルされる可能性が高い（『ThunderBarとそれを支えるGloda』参照）。新しいUIに適応したいけれども、ヘッダ領域のボタンは特徴に乏しいためそれも難しい。ぜひ修正してほしい個所だ。
なお、ヘッダ領域で差出人などをクリックすると、連絡先の編集画面を呼び出せる。アドレス帳に登録済みかどうかはスターアイコンの色でわかるようになっていて便利である。
タブは、複数のメッセージを並べておいて［Ctrl］＋［Tab］キーで切り替えられるので、メールをたくさん読む人は重宝するだろう。ただ、今のところタブはフォアグラウンドで開かれ、常にバックグラウンドで開くように変更するオプションがない。つまり、新しいタブを開くたびに、そちらにフォーカスが移ってしまう。ここも改善の余地があると感じた。
Beta 2の目玉といえば
アーカイブはThunderbird 3 Beta 2の新機能である。メールを選んでヘッダ領域の該当ボタンを押せば、自動的にアーカイブフォルダが作られて、メールが移動する。フォルダは月ごとに分けられている。
受信トレイやユーザーが作成したフォルダには、重要なメッセージだけを残し、削除するほどではないメッセージはまとめてこのアーカイブに入れておけば、検索によっていつでも引き出せるという仕掛けだ。ただ、Thunderbird 3に強力な検索機能が導入されるのはBeta 3からなので、今はまだその真価を発揮することができない。
また、検索の点を脇に置いても、UI的に不満が残る。たとえば、複数のメールを選択した場合だ。このときボタンは消えてしまうので、メッセージメニューを呼び出せばアーカイブできるとはいえ、右クリックメニューに「アーカイブ」の項目がほしいところ。
加えて、アーカイブフォルダが受信メールと送信メールを区別しないのも不親切だ。常に検索機能を使って探すとは限らないからである。ただ、この点はGlodaデータベースが動き出せば解決しそうだ。主要開発者のブログ記事にも、受信トレイ、送信トレイと下書きを区別すると書かれている。
もう一つBeta 2の目玉機能と呼べるのが、アクティビティ・マネージャで、「イベントログの管理」と訳されている。Firefox 3のダウンロードマネージャに似た画面に、ユーザーの操作記録が順番に記録されていく。
実は、この機能は使い勝手が悪い。プログラムを終了すると、ログが消えてしまうからだ。延々と記録されても見にくいかもしれないが、セッションごとに管理できるようにすればそれほどでもないように思う。いつ起動したときの記録なのかを明示し、セッション単位で表示・非表示・削除を選べるようにする。また、メールと同様にタグが付けられるようにして、たとえば「重要」とした記録だけを検索できるようにする。こうした工夫が加えられなければ、ほとんど活用されずに終わってしまう気がする。
縁の下の力持ち
最後に、他ではあまり語られないと思うので、バックエンドの変更にも触れておこう。
Beta 2では、パスワードマネージャのコードがFirefox 3.1と共通のものになった（Bug 433316）。これにより、パスワードはsignons3.txtというテキストファイルではなく、signons.sqliteというデータベースファイルにレコードとして記録される。暗号化されているとはいえ、テキストファイルは簡単に開くことができるので、データベースに格納されたほうが安全だといえる。そして、大量のパスワードを処理する際のパフォーマンスも向上している。
メモリ管理システムをFirefox 3で導入されたjemallocに変更した点も特筆すべきだろう（Bug 427627）。対象はWindowsとLinuxで、Macは含まれていないようだ。Bugzillaのコメント欄を見る限りでは、メモリ割り当て量が4％削減され、ウォームスタートのスピードが3％向上したという。
（09/03/05追記）
「えむもじら」の『Thunderbird 3 Beta 2 インプレッション』と「やってMotors」の『Thunderbird 3 Beta2 記録』シリーズも併せて読むことをおすすめする。
Permalink | コメント(0) | トラックバック(0) | 08:08 
バグに関する話題 090302版
最新のShiretoko Nightly（3.1b3pre, ID:20090301033810）で目立つのは、browser.identity.ssl_domain_displayのデフォルト値が、0から1に変更されたことだろう（Bug 480357）。これによって、SSL接続時には「Effective TLD + セカンドレベルドメイン」がfavicon右横に表示される。設定一般についての詳細は、「鳥獣保護区」の該当記事を参照していただきたい。
たとえばMozilla Wikiにアクセスすると、サイトアイコンにmozilla.orgの文字が現れる。背景は従来どおり青なので、EV SSL接続と勘違いすることはない。今回の変更は決定事項ではなく、ユーザーのフィードバック次第で元に戻すこともありうるそうだが、筆者はこのままいくべきだと考えている。たしかに、URLを表示可能な領域が減るのを嫌う人もいるだろう。だが、SSL接続時は、ユーザーがサイトアイコンをクリックして認証局を確認するのが望ましい。その望ましい行動を促すうえで、サイトアイコンが色以外にも表示を変えるのは効果があると思う。このメリットは、URLの表示領域が少し減るデメリットを大きく上回っている。
次のトピックに移ろう。Alice0775氏が取り上げているバグの話題に興味を惹かれた。未解決のまま放置されているが、そのせいでユーザーがFirefoxをメインブラウザとして使うのをためらってしまうようなバグがあるという。そのうちの一つが、"Bug 372039 - [Fx3] Slow and laggy scrolling with fixed background, high CPU usage"である。スタイルシートで背景画像を固定したWebページでは、高いCPU負荷がかかり、スクロールが遅くてカクカクしたものになるとの報告だ。
このバグレポートにはテストケースが付いている。これがとてもよくできていて、ベンチマークとしても使える。画面左上のボタンを押すと、ページが自動的にスクロールし、最後に経過時間を表示してくれるのだ。
次のWebブラウザを対象に、3回ずつ計測してみた。また、タスクマネージャでCPU使用率をチェックし、最高値をピックアップした。
Firefox 3.0.6
Firefox 3.1 Beta 2
Shiretoko（3.1b3pre, ID:20090301033810）
Google Chrome 2.0.166.1（WebKit/530.1）
| Fx 3.0.6 | Fx 3.1b2 | Fx 3.1b3pre | Chrome 2.0 | |
|---|---|---|---|---|
| 1回目 | 8006ms | 4664ms | 4674ms | 4428ms |
| 2回目 | 7775ms | 4656ms | 4578ms | 4429ms |
| 3回目 | 7984ms | 4810ms | 4634ms | 4378ms |
| CPU負荷 | 39％ | 67％ | 61％ | 68％ |
本バグは、当初Firefox 3を対象にしたものだった。計測してみると、3.0.6はたしかに遅い。その一方で、CPU負荷は最も軽いことがわかる。
これに対し、Firefox 3.1 Beta 2を見ると、スピードが大幅に改善した代償として、CPU負荷は非常に高くなった。だが、それを3.1の欠陥といえないことは、速さに定評のあるChrome 2.0と比較すれば明らかだ。最速のスクロールを誇るChromeは、CPU負荷でFirefox 3.1 Beta 2に並ぶのである。
Shiretokoはスクロール速度とCPU負荷の両面で3.1 Beta 2に勝る。つまり、3.1 Beta 3はBeta 2から着実に進歩している。
もちろん、経過時間やCPU負荷はユーザーの環境次第で大きく変動するだろう。それでも、だいたいの傾向はこれで把握できた。PCの性能向上を踏まえれば、CPU負荷がかかってもスクロールが速いほうが使い勝手はよさそうだ。また、現時点で既に、Firefox 3.1の開発版はスクロールが「遅くてカクカクしたもの」にはなっていない。3.1正式版が出る頃にはなおさら、メインブラウザとして使うのをためらう理由にはならないはずである。
最後に、以前取り上げた"Bug 479739 - Make location bar autocomplete even faster"のパッチがTrunkに入っていることを指摘しておきたい。Minefield/3.2a1preでは既にスマートロケーションバーの処理が高速化された。現在、Branchへのチェックインを承認してもらえるよう申請しているところだ。ユーザーからのフィードバックを集めるならBeta 3が最適なので、承認されるのではないかと密かに期待している。
Permalink | コメント(0) | トラックバック(0) | 07:06
私信的なもの #5
「えむもじら」のlevelさんと「Firefox Hacks 翻訳日記」の池田譲治さんから、過分なお褒めの言葉をいただきました。心よりお礼申し上げます。お二人は有名な『Firefox 3 Hacks』の著者であり、日本のMozillaコミュニティを支えてこられた方々です。この上なく励みになるとともに、身の引き締まる思いがしました。
量と速さにつきましては、正直なところ今後も維持できるか難しいところもあります。しかし、せめて質だけは保っていきたいと考えております。とはいえ、私の知識や技量は非常に心許なく、お二人からもいろいろとご教示願いたく存じます。
また、お二人の記事を楽しみにしております。池田さんのお話では、（Firefoxにとって）「IE8 なんかこわくない」理由をお書きになるとのこと。ぜひ読みたいと思います。
Permalink | コメント(0) | トラックバック(0) | 07:02
*1：正式版のリリース時にはGecko 1.9.1も完成している。
