Latest topics 近況報告

アドオンのレビューのガイドライン - Jul 10, 2009

レビューガイドライン :: Firefox Add-onsが日本語に訳されてなかったのでがっくり来て、なんとか読み解いてみた。

最後まで読んでみて思ったこと：誰もガイドライン守ってなくね？

レビューのガイドライン

アドオンのレビューは、アドオンサイト（AMO）のユーザがインストールして使っているアドオンについて、意見を共有するための手段です。編集者（エディタ）は、このガイドラインに従っていないレビューを拒否したり削除したりする権限を持っています。

良いレビューを書くためのいくつかのtips

するべき事：

• そのアドオンであなたがどのような体験をしたかを、友達に語るように書きましょう。
• 簡潔で分かりやすいレビューを書くよう心がけましょう。
• 明瞭且つ有用な詳細を書きましょう。例：
  • そのアドオンはあなたが期待したとおりに動きましたか？
  • あなたが好きな、あるいは嫌いな機能は何ですか？
  • 便利でしたか？
  • 簡単に使えましたか？
  • そのアドオンを使い続けたいと思いましたか？
• 恥ずかしいミスタイプや文法のミスを公にしてしまわないように、レビューを送信する前にきちんと時間を取って読み返しましょう。
• レビューは長期間にわたってサイト上に掲載され続ける可能性があります。時事的な話題への言及は避けましょう。

してはいけない事:

• 「すごい！」「素晴らしい！」「使えない」などのような、説明がなされていない短いレビューは投稿しないで下さい。
• バグや障害のレポートをレビューに含めないで下さい。代わりに、それぞれのアドオンのサポート用連絡先を使って下さい。
• 個人的に使ってもいないアドオンのレビューを書かないで下さい。
• 罵倒、性的な言葉、人を不快にさせるような言葉を使わないで下さい。
• HTML、悪意のあるソフトウェアへのリンク、ソースコードやコード片をレビューに含めないで下さい。レビューには文章だけを書いて下さい。
• 嘘、アドオンの作者への罵倒、個人への侮辱を書かないで下さい。
• 特定のFirefoxのバージョンや他のアプリケーションへの対応を要求するための場としてレビューを使用しないで下さい。
• あなたのメールアドレス、電話番号、あるいはその他の個人情報を書かないで下さい。
• あなた自身やあなたが所属する組織が提供しているアドオンにレビューを書かないで下さい。

アドオンの評価のガイドライン

アドオンの評価は、公正で且つ、総合的な品質と便利さを示すための指標を示す物であるべきです。そのアドオンが単に好きだから5つ星を付けたり、単に嫌いだから星を1つだけ付けたり、といった評価をしないで下さい。あらゆるレビューにおいて、一貫した評価付けは重要な点です。

• 5つ星：非常に素晴らしい場合。説明されている特徴がすべて動くだけにとどまらず、他の多くのアドオンに比べて際立って便利である。このアドオンは自分にとって常用に足るもので、他の人にも強くお勧めできる。
• 4つ星：良くできている場合。特別に凄いわけではないけれども。便利で、簡単に使うことができる。このアドオンはお勧めできるが、人によってはよりお勧めなアドオンがあるかもしれない。
• 3つ星：可もなく不可も無しという場合。不足している機能があったり、設計に問題があったりするかもしれない。既知の問題はそのアドオンを使わないことを強く勧めるほどの重大なものではなく、それでもなお便利に使えるという人もいるかもしれない。その機能を必要としていて、試してみることを厭わない人には、お勧めできる。
• 2つ星：あまりできが良くない場合。そのアドオンは完成度が低いか、使いにくいか、または、説明でうたわれていることを実際にはできない。それでも、ごく少数の人達にとってはそれでも使う価値がある場合には、お勧めすることができる。
• 1つ星：駄目な場合。そのアドオンは正常に動作しないか、全く役に立たない。使ってみる価値があるような重要な理由は無いと考えており、完全に避けることをお勧めする。

完全な、あるいは非常に詳細なレビューを書くことがどうしてもできないのでなければ、何故その評価を下したのかを示して下さい。何も説明が付いていないと、評価の星は何の意味も持ちません。

レビューについてのよくある質問

問題のあるレビューはどうやって報告すればよいですか？

疑わしいレビューについては、「このレビューを報告」をクリックして、フラグを立てて報告して下さい。報告の内容は編集のためにサイトに送られます。エディタはそのレビューを削除するか、それとも元に（サイト上に表示される状態へ）戻すかを判断するために、このレビューガイドラインを用いるでしょう。

私はアドオンの作者ですが、レビューに返信してもよいですか？

はい。アドオンの作者は1つのレビューにつき1つの返信を書くことができます。それ以上の議論やフォローアップは、サポートフォーラムや議論のためのグループに移動するべきです。

私はアドオンの作者ですが、好ましくないレビューや評価を削除してもよいですか？

一般的には、駄目です。しかし、上述したガイドラインに則っていないレビューに遭遇した場合は、「このレビューを報告」をクリックして、エディタに報告することはできます。もしそのレビューが、あなたのアドオンの新しいバージョンですでに解消された問題についての苦情を含んでいる場合、私たちはそのレビューを削除するかもしれません。詳細な説明込みでの削除要求は amo-editors@mozilla.org へ送って下さい。

タブをグループ化するためのダミーのタブ（How to open a custom dummy tab to put tabs in a group?） - Jul 10, 2009

Q

I noticed that you have added support for dummy tabs to group tabs when opening multiple links from the bookmarks menu. This is very close to a feature that I've wanted since I began using this extension a few months ago: to have general dummy tabs available so that I can create and name a dummy tab from the tab bar context menu.

Is it possible to implement this?

ブックマークメニューから複数のページをタブで開く時に、それらをグループ化するための物として、ダミーのタブがサポートされましたよね。これは、私がこのアドオンを使い始める前に求めていた機能にとても近いです。その機能とは、タブバーのコンテキストメニューから任意にこのようなダミーのタブを開き、自由に名前を付ける事ができるというものです。このような機能を実装してくれませんか？

A

On Tree Style Tab 0.7.2009071001, I made dummy tabs customizable. To change the name of an existing dummy tab, switch to the tab and click the label in the content area (or double-click on any position in the content area). It possibly helps you that you create a bookmark for "about:treestyletab-group?(new group)" and put it in the bookmark toolbar.

ツリー型タブ0.7.2009071001において、ダミーのタブをカスタマイズできるようにしました。既にあるダミーのタブの名前を変えるには、そのタブに切り替えて、内容領域のラベル文字列部分をクリックしてください（または、内容領域のどこか適当な所でダブルクリックしてください）。「about:treestyletab-group?(new group)」というURIのブックマークを作成してブックマークツールバーに置いておくと、あなたの助けになるのではないでしょうか。

ツリー絡みの機能ではないので、「ダミーのタブを開くための機能」は付けない予定。なのでブックマーク等で代用してもらう必要がある。

実装の仕方は、「about:treestyletab-group」というabout: URLを使えるようにするためのコードと、表示する内容の実体と、スタイル定義を見ると分かると思う。XHTMLの名前空間のlink要素を埋め込んでfaviconを変えるとかの姑息なテクニックを使ってます。Firefox 3.5でサポートされた-moz-transformは今回初めて使った。

en-USでは定義されてて他のロケールで定義されてないエンティティ参照の有無を調べるスクリプトを書いてみた - Jul 09, 2009

機能を追加した時にen-USに追加したエンティティを他のロケールに追加し忘れて「○○語の環境で設定画面が動かねえぞゴラァ！！！」という風なバグ報告を貰うことがあまりに多いので（そして自分で気づけないので）、そういうミスを事前に防ぐためのスクリプトを書いてみた。

find_missing_entries_from_locales.js

コンテキストメニュー拡張などの、任意のスクリプトをXPConnect特権付きで実行できるツールでこのスクリプトを実行すると、以下のように動作する。はず。

1. フォルダ選択のダイアログが開かれる。
2. localeフォルダ、またはその上位の任意のフォルダを選択する。
3. その中にある*.dtdなファイルがすべて読み込まれる。
4. en-USロケールでは定義されていて他のロケールで定義されていない、というエンティティの一覧が表示される。

ブックマークを常に新しいタブで開く機能（A new option to open any bookmark in new tab is required.） - Jul 07, 2009

Q

I can't tune firefox for force opening links from bookmarks with left-click always in new tab. Tab Mix Plus have this option in Settings, but your extension didn't have. Can I tune your extension to enable opening new tab from bookmarks via left-click?

Firefoxでブックマークを左クリックした時に常に新しいタブで開くようにしたいです。Tab Mix Plusにはその設定がありますが、あなたのアドオン（ツリー型タブ）にはありません。そういう設定ができるようになりませんか？

A

Sorry, I have no plan to add features not related to "tree" to Tree Style Tab... Instead, it is designed to work with other tiny addons together, so I hope you use TST with other addons.

BTW, Open Bookmark in New Tab does it.

ツリーと関係ない機能をツリー型タブに加える予定はありません。その代わりに、ツリー型タブは他の小さなアドオンと協調して動作するように作られていますので、他のアドオンと組み合わせて使ってください。

ちなみに、ブックマークを新しいタブで開くはそのためのアドオンです。

この要望は非常に多い。もはや定型文。

ウィンドウにフォーカスするとタブの色が変わる（Colors of tabs is changed when the window is focused/unfocused!） - Jul 07, 2009

Q

The minor bug is the changing of the background color of the tree bar. In the screen shot included you can see that it is light grey. But when I change focus to Firefox the tab becomes dark grey and all the tabs darken too.

（他のバグ報告と併せて）もう1つ些細な問題として、ツリー表示されたタブバーの色が上げられます。このスクリーンショットではタブは明るいグレーで表示されています。しかしFirefoxのウィンドウにフォーカスすると、タブが暗いグレーで表示されるようになり、他のタブの色も暗くなります。

A

Do you talk about the changing of tab colors caused by focusing/unfocusing of Firefox window? Then, it is not a bug, but a design. The "Metal" theme (one of built-in theme of TST) is designed for Mac OS X. In the platform, any window which have no focus is shown with paled colors.

Firefoxのウィンドウにフォーカスしたりフォーカスを外したりした時の色の変化についての指摘であれば、それはバグではなく仕様です。ツリー型タブの組み込みテーマの1つである「Metal」はMac OS X用にデザインされており、Mac OS Xではフォーカスを持たないすべてのウィンドウは薄い色で描画されます。（つまり、その挙動に併せてタブの色が変わるというわけ。）

WindowsやLinuxだと確かに違和感あるか……

バイナリをBase64エンコードする - Jul 07, 2009

var file = Cc['@mozilla.org/file/local;1']
            .createInstance(Ci.nsILocalFile);
file.initWithPath('C:\\temp\\target.jpg');

var fileStream = Cc['@mozilla.org/network/file-input-stream;1']
                  .createInstance(Ci.nsIFileInputStream);
fileStream.init(file, 1, 0, false);
var binaryStream = Cc['@mozilla.org/binaryinputstream;1']
                    .createInstance(Ci.nsIBinaryInputStream);
binaryStream.setInputStream(fileStream);
var bytes = binaryStream.readBytes(fileStream.available());
binaryStream.close();
fileStream.close();

var base64 = btoa(bytes);

Bug 364586 - nsXmlRpcCLient.js conversion to base64 is slowで「JavaScriptでBase64エンコードするの遅いから組み込みの関数使えやゴラァ」と提出されていたパッチを見て知った。バイナリファイルの内容をバイト列の配列として読んでゴニョゴニョしなくても、単純に、バイナリのインプットストリームからreadBytes()でバイト列を文字列として取得してbtoa()にかければOK、だそうだ。試してみたら確かにちゃんといけた。

Vista-aeroとツリー型タブの共存（Vista-aero theme with Tree Style Tab） - Jul 06, 2009

Q

It seems to collide with a Firefox Theme: Vista-aero. Is there a chance to fix this?

（ツリー型タブは）Vista-aeroというテーマと衝突するようです。この問題は解決されますか？

A

Vista-aero modifies internal structure of Firefox too much, so, it is too hard to make Tree Style Tab compatible with the theme. I cannot take much time for the task. Instead, I recommend you to choose another theme which provides only appearance, not other features including buttons beside tabs.

Vista-aeroはFirefoxの内部構造を激しく変更するので、ツリー型タブをそのテーマと同時に動くように修正するのは非常に困難です。そのための時間を割く事が私にはできません。代わりに、タブの横のボタンなどの余計な機能を提供しない、単に見た目だけを変更するテーマと組み合わせて使う事をお勧めします。

テーマへの特別な対応は、あっさり解決できる場合を除いて、なるべくしない方向です。

タブのフォーカスをホイールスクロールで切り替える（A new option to move focus of tabs by wheel scrolling is required.） - Jul 06, 2009

Q

One of the simplest features that I miss however is the possibility to scroll through the tabs using the mouse wheel. This is soooo convenient, try it out :-) TabKit, for example, includes this one and it adds so much to the browsing experience that I would never want to surf the web without it.

タブの上でホイールをスクロールしてタブのフォーカスを切り替える機能が欲しいです。

A

Sorry, I have no plan adding the feature, because I hope to keep Tree Style Tab as simple as possible. This policy is based on reflection on my past mistakes about a too fat addon, Tabbrowser Extensions. I recommend you to use TST with other tiny addons providing the feature...

ツリー型タブを可能な限りシンプルに保ちたいので、そのような機能を加える予定はありません。このポリシーは、過去の肥大化したアドオン「タブブラウザ拡張」の開発における失敗についての反省に基づいています。私は、そのような機能を提供する他の小さなアドオンと一緒にTSTを使う事をお勧めします。

ツリーに関係ない機能の追加要望には基本的にこう回答してます。

「このツリーを閉じる」（A new button "Close This Tree" is required.） - Jul 06, 2009

Q

One improvement I would like to see is an icon on the tab to close the entire tree, instead of having to right click and select "Close this tree".

メニューから「このツリーを閉じる」を選ぶ代わりに、ツリー全体を閉じるためのボタンが欲しいです。

A

Did you try the action, clicking on "close" button when the tree is collapsed? Closing of the parent tab with collapsed children will close the entire tree by one action.

ツリーを閉じた状態でタブの「閉じる」ボタンをクリックしてみましたか？　この操作でツリー全体を閉じる事ができます。

Q

I have the options set to always have my tabs always expanded. It saves a few clicks... and I have plenty of screen real estate. So my tabs are never collapsed.

私はすべてのツリーを常に展開した状態にする設定にしています。なので、ツリーを閉じる事ができません。

A

Hmm, OK, I realized what you are suffered from. However, I think I shouldn't add new buttons anymore into each tab because there are too less spaces...

If you told about a new toolbar button, then, this will help you:

TreeStyleTabService.removeTabSubTree(gBrowser.selectedTab);

By another addon which provides customizable toolbar buttons or customizable shortcuts, you can do "close this tree" by the code.

タブの中があまりに狭いので、これ以上ボタンを追加するべきではないと私は思います。代わりに、カスタマイズ可能なツールバーボタンやキーボードショートカットを提供する他のアドオンでこのコードを使うと、現在のツリーを閉じる事ができます。

読み返してみるとなんともチンプンカンプンで的外れな回答だと思った。

Fennecの構造 - Jun 19, 2009

Fennecのどんなところがマズいわけ？という話の中で、canvasがどうしてそこででてくるのか、Fennecって実際どんな作りになってるんだ、というツッコミを受けた。なので簡単に解説してみる。

しばらくソースを見るとだんだん分かってくるんだけど、要約するとこんな風になってる。

<window>
  <html:canvas id="browser-canvas"/>
  <box id="browsers" hidden="true">
    <browser/>
    <browser/>
    ...
  </box>
</window>

Firefoxのtabbrowser要素に相当する物は主にJavaScriptで実装されている。canvasは現在フォーカスされているタブに対応するbrowser要素の内容を描画するための物で、1つだけしか存在しない。パンスクロールやズームは全てこのcanvasの再描画でまかなわれてる。ユーザの目に見えているのはこのcanvas要素で、実際のページの内容は画面外の非表示のbrowser要素の中に置かれている。

• ページの読み込みが完了した時→browser要素の内容をdrawWindow()でcanvasに描画する。
• パンスクロールする時→canvasを制御するコントローラにあたるJavaScriptオブジェクトが保持している座標情報を変更して、canvasに描画する範囲を変更する。
• ズームする時→canvasに描画する内容のズーム率を変える。
• ユーザがリンクをクリックした時→canvas上の座標、パンスクロールの位置、ズーム率の3つから、browser要素内の実際のページにおけるクリック位置を算出して、nsIDOMWindowUtilsの機能でマウスイベントを実際のページに送出する。
• アニメーション等で再描画が発生した時→browser要素の中にあるページ上で、再描画された箇所の座標情報を持ったMozAfterPaintイベントが発行される。それをFennecのイベントハンドラが検知して、パンスクロールの位置とズーム率を元に「再描画された箇所に対応するcanvas上の座標」を計算し、必要最低限の領域だけ再描画を行う。

何故こうなっているかというと、ズームとスクロールのパフォーマンスの問題かららしい。具体的には、Firefox 3以降のフルズームを使った場合、ズーム率を変えるごとにreflow（ボックスの位置等の計算）が発生してしまうなどのせいでパフォーマンスが落ちてしまうため、使い物にならない。そこで、高速な再描画ができるcanvasが使われることになったということのようだ。

だから現状では、FirefoxでcanvasとdrawWindow()を使った時に起こる問題が全部未解決のまま積み上がってる。例えばFlashなどのプラグインによって描画される箇所はスッポリ抜けるし、select要素のように独自の「ウィンドウ」を形成する物は見当違いの場所にポップアップが出る。そういった問題は当然解決されるべきだ（そして実際、Gecko 1.9.2以降で修正することを目指しているらしい）けれども、それって却って遠回りなんじゃないの？　というのが、自分の率直な感想。