Latest topics 近況報告

現在のタブを閉じた後のフォーカス移動を制御するオプション（A new option to control focus of tabs when the current tab is closed is required.） - Jul 22, 2009

Q

I wonder if you consider integrating Tab Mix Plus into Tree Style Tabs? Not all of Tab Mix Plus but just the opening/closing/focus behavior (under "events" options of Tab Mix Plus)?

There is a lot of interaction between Tree Style Tabs and Tab Mix Plus. Some things don't work correct because Tab Mix Plus is very slow to update. For example, "duplicate tab" used to work in firefox 3.0, but in 3.5 it doesn't work right and Tab Mix Plus had not fixed it (the error is that the duplicate tab gets stuck in middle of tree).

Also Tab Mix Plus doesn't have enough options to give good control over Tree Style Tabs. So maybe it's better if Tree Style Tabs has own options.

Could you copy Tab Mix Plus code for opening/closing/focus, then add some new options for Tree Style Tab? For example:

• If close first child tab, focus: up/down
• If close middle child tab, focus: up/down
• If close last child tab, focus: up/down
• If close only child tab, focus: up/down
• If close sub-parent tab, focus: up/first-child/last-child
• If close expanded root-parent tab, focus: tab-above/parent-tab-above/first-child-down/last-child-down/

Tab Mix Plusをツリー型タブに統合するつもりはないでしょうか？　TMPの全機能でなくとも、単にタブを開く・閉じる・フォーカス関係の挙動（TMPの設定の「イベント」パネルにある機能）だけでもいいんですが。

ツリー型タブとTMPの間には互換性がありますが、TMPの更新が非常に遅いため、いくつかの機能は正常に機能しません。例えば、「タブの複製」はFirefox 3.0では動いていましたが、Firefox 3.5では正常に機能せず、TMPはまだその問題を解決できていません（複製されたタブがツリーの真ん中に現れてしまうという問題があります）。

また、TMPはツリー型タブの挙動を制御するのに十分な数の設定項目を備えていません。ツリー型タブ自体がそのような設定項目を備えることが望ましいのではないでしょうか。

タブを開く・閉じる・フォーカス関係のTMPのコードをコピーして、ツリー型タブに新しい設定項目を加えてもらえないでしょうか？　例えば……

• 最初の子タブを閉じた時：上にフォーカス/下にフォーカス
• 真ん中の子タブを閉じた時：上にフォーカス/下にフォーカス
• 最後の子タブを閉じた時：上にフォーカス/下にフォーカス
• 最後の子タブを閉じた時：上にフォーカス/下にフォーカス
• 他のタブの子である親タブを閉じた時：上にフォーカス/最初の子にフォーカス/最後の子にフォーカス
• ツリーが展開されている最上位の親タブを閉じた時：上にフォーカス/親にフォーカス/最初の子にフォーカス/最後の子にフォーカス

A

Thank you for interesting idea. To be honest, I received some similar suggestions about tab focus of Tree Style Tab. However, I couldn't agree them because I hope to keep Tree Style Tab as simple as possible.

There are three reasons why I implemented only minimal options about tab focus.

1. "Focus last selected" behavior is available with other existing addons.
2. "Focus to upper (left) tab" hebavior was made obsolete by an old bugfix of Mozilla.
3. Options dialog will become too complex.

1) Very special behavior, "focus to last selected tab when the current tab is closed" is available with known tiny addon, "Focus Last Selected Tab". So I'm recommending people to use the addon with TST. (BTW, Focus Last Selected Tab 0.9.x doesn't work with TST correctly, so I'll update TST as soon.)

2) For other cases, I don't agree to add "focus to upper (left) tab" option, because it was the default behavior of old Mozilla and it was "fixed" by usability reason. See bug 123563.

3) As you know, too many options for detailed cases will confuse people including me. So I have to make effort to reduce checkboxes, radiobuttons, and so on. Then, TST already have options to customize behavior of re-structuring tree after the current "parent" tab. I'm using the choice "raise the first child up to the new parent", but people can use others. How to unify options for two features, re-structuring and focusing? I cannot imagine to do it in the small dialog...

Anyway, this is only my policy, not the best answer. If people really want options for the feature, I hope that TST is extended by other developers like Tab Mix Plus born from Tab Mix.

興味深い意見をありがとうございます。正直に言うと、この手の提案は他にもたくさん受けています。しかし、私はツリー型タブを可能な限りシンプルに保ちたいので、これらの提案には同意できません。

タブのフォーカスに関して最小限の設定項目だけしか設けていないのには、以下の3つの理由があります。

1. 「現在のタブを閉じた時、最後に選択されていたタブにフォーカスする」という挙動は、他の既存のアドオンで実現できる。
2. 「現在のタブを閉じた時、上（左）のタブにフォーカスする」という挙動は、Mozillaの過去のバグ修正によって廃止された物である。
3. 設定ダイアログが非常に複雑になってしまう。

1) 「現在のタブを閉じた時に、最後に選択されていたタブにフォーカスする」という非常に特殊な挙動は、既存のよく知られたアドオンFocus Last Selected Tabで実現できます。なので私は、それとツリー型タブを使うことをお勧めしています。（ちなみに、Focus Last Selected Tab 0.9.xはツリー型タブと組み合わせると期待通りには動きません。この点についてはなるべく早くツリー型タブを更新するつもりです。）

2) それ以外の挙動について、私は「現在のタブを閉じた時に、上（左）のタブにフォーカスする」という設定項目を設けることには同意しません。なぜなら、その挙動は古いMozillaの既定の挙動であったものの、利便性の観点から「（問題であるという認識の上で）修正された」からです。詳しくはbug 123563を見て下さい。

3) 言うまでもなく、詳細な場合ごとの過剰な数の設定項目は、私を含めてユーザを混乱させます。なので私は、チェックボックスやラジオボタンなどの数を減らす努力をしないといけません。ツリー型タブはすでに、親タブを閉じた後のツリーの再構築についての設定項目を備えています。私は「最初の子を新しい親にする」という選択肢を使っていますが、他の人は別の選択肢を使っているかもしれません。これら2つの機能（親タブを閉じた時のツリーの再構築と、現在のタブを閉じた時のフォーカスの移動）の設定項目をどのように統合すればいいでしょうか？　私には、それを小さなダイアログの中でやってのける様子が想像できません。

ともかく、これはあくまで私のポリシーであって、最良の答えというわけではありません。もしみんなが本当にその機能のための設定項目を必要としているのなら、Tab MixからTab Mix Plusが生まれたように、他の開発者の人がツリー型タブをさらに拡張してくれることに、私は期待します。

英語でどう書けばいいのか分からなかったんでこういう書き方になったけど、ぶっちゃけ、「カスタマイズのためのチェックボックスやドロップダウンリストは多ければ多いほどいい」という発想には反吐が出る。そういうことは隠し設定で十分だろ、と。about:configでやりゃいいだろ、と。何でもかんでもダイアログの中に詰め込むという発想は、僕がかつて取り憑かれそして我が身を滅ぼすに至った忌むべき考え方だ、と僕は認識している。

タブをグループ化するためのダミーのタブ（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は今回初めて使った。

ブックマークを常に新しいタブで開く機能（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だと確かに違和感あるか……

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.

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

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

ツリー型タブとマルチプルタブハンドラのAPIドキュメントの追加 - May 16, 2009

not enough memory - snj: 最近，Firefoxはもっと拡張間で連携プレーした方が良いんじゃないかって思ってきた．...

リンク先に書かれてる話からは少しズレる。どちらかというとこの前書いた互換性の話の方だ。

アドオン同士で連携するには、機能が使いやすくまとまってるということが当然必要だけど、それだけでなく、外部から安心して使えるということも非常に重要だと思う。公開されていて、今後のアップデートでも後方互換性が保証されていないと、安心して使えない。「ソースを掘り返してこういう機能を見つけたから使ってみてるけど、これって知らんうちに削除されてしまったりしないか？」という不安があってはいけない。機能が「今のバージョンにあるかないか」ではなく、「今後もあり続けるのかどうか」が重要だと思う。

ツリー型タブは以前からいくつかAPIを公開してはいたけど、基盤になる処理をもっと公開APIとして表に出すことにした。公開した物は原則として後方互換性を維持していく方針でいる。

• ツリー型タブの公開API

マルチプルタブハンドラの方も地味にAPIを整備している。

• マルチプルタブハンドラの公開API

もう僕は疲れたんで、この辺使ってよろしくやってくれってことで……

Tim O'Reilly on Twitter - Apr 21, 2009

Tim O'Reillyを名乗るTwitterアカウントからリンクされてた（ツリー型タブが紹介されてた）わけですが。

……これ、騙り？　ボット？

いずれにせよとりあえず1つだけ言えることは、「プラグインゆーな！」ということですかね。（←そこかよ）

他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009

「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。

現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んでいくと、どこかで破綻すると思う。機能の詰め込みは、ある時点までは効率がいいんだけど、ある時点を超えてしまうと、デメリットの方が大きくなってくる。「Piro拡張化」なんて言われるようになる。

作る側の心理として、どうして機能を増やしたくなるのか。他の人はどうか知らないけど、僕はこんな感じだった。

• デバッグより、新機能を実装する方が楽しい。モチベーションが高まる。
• 大は小を兼ねる。大きいことはよいことだ。みたいな。
  • 「こんな小さな物をたくさん作りました」よりも「こんなデカい物をたった一人で作りました」の方がなんかすごそう。
  • より多くの人のニーズを満たせば、より多くの称賛を得られる。誉められて嬉しい。
• それまでに作った部分を土台や部品として使えるので、新しい別個のアドオンにするのに比べてはるかに楽に「すぐ動く物」ができる。
  • 共有できる部分が多ければ、それだけ「無駄が無い」と言える。同じことをするコードが複数のアドオンにあるのは、無駄なことで、気持ち悪いと感じる。
  • 複数の機能を有機的に連携させて、「100％ぴったり、思い通り」の挙動を実現できる。

そんな感じの理由でどんどん機能を加えていく。ある時点までは、それでうまく回る。応援してくれる人とか感謝してくれる人とか、モチベーションを高めてくれる声も寄せられる。でも、なんかの閾値を超えたところで、あらゆる物事が下り坂に転じる。

• 目が行き届かない所が出てくる。
  • 自分が使う物は目が届くけど、使ってない機能には目が届かない。
  • 自分の環境では問題ないのに他の環境では問題が起こる、というケースが頻発するようになる。
• 機能同士が複雑に絡み合っているので、原因の特定がどんどん困難になる。
• 既にある機能との整合性を常に考えないといけないため、新しい機能を加えにくくなってくる。新しい機能を加えることに物凄くエネルギーを使わないといけなくなる。
• 作り込めば作り込む程、前提とする環境への依存が強くなる。
  • 前提がちょっと変わるともう全然動かなくなる。Firefox 1.5向けに作り込んでいたから、もはやFirefox 2に対応できない。
• 最初の頃は「こんなの今まで無かった！　これがあると大違い！　素晴らしい！」と称賛されていたのに、だんだんそれがなくなってくる。
  • 「定番だよね」「むしろ当たり前だよね」と言われるようになってくる。
    • 使う側から見たら「あって当たり前」という感覚だから、感動なんてしない。最初の時点で「とりあえず入れとけ」みたいな感じで勧められるから、それが無い時の不便さも、それを導入することで起こる変化にも、気がつかない。
    • 本当だったら使わなくてもいいはずの人まで、「なんかみんな使ってるみたいだし、入れとくか」という感じで使うようになる。
    • アドオンは薬のようなもので、導入するのは薬効と副作用のトレードオフ。どうしても必要な薬効があるから副作用を我慢して使う、というのが本来そうあるべき使い方なのに、薬効をそもそも知らないまま流されて服用して、副作用に苦しむことになる。
      • 「バグが多い」「不具合ばっかり」「他のアドオンと衝突しまくる」などのデメリットばかりがとりあげられるようになってくる。
    • 「定番なんだから責任持って作れよ」「こんな事もできないの？　定番なんだからできて当然なんじゃないの？」みたいな、お客様気分の声が増えてくる。やる気を削がれてくる。

そんなわけで、精神的な負荷と時間的なコストがどんどん大きくなっていって、タブブラウザ拡張は破綻した。Firefox 1.5のサポート完全終了と共に、過去の遺物となった。

• かといって、Firefox 2デフォルトの状態で我慢できるわけもなくて。
• でも、タブの複数行表示機能をやめてツリー表示しか使わなくなってしまっていた自分には、今更Tab Mix Plusに乗り換えるというのも考えられなかった。
  • 感情的な理由もあった。後から来て追い抜いていった（と同時に、良い評価もかっさらっていった）相手に自分が依存するのは屈辱だと思った。
  • TMPも「Piro拡張化」の行き着く果てまで来ているように思えた。ここから先は下り坂だと思った。

そういうわけで、過去の自分の失敗を徹底的に反省して、ゼロからやり直すことにした。

• 全部詰め込むのはやめる。1つ1つのアドオンを可能な限り単機能に保つようにする。
  • 多少効率が悪くても、重複する部分があっても、個別のアドオンに分ける。
  • 重複する部分がデカくなるようだったら、ライブラリにする。
    • ライブラリはファイル単位で上書きできるようにする。ファイルの中を見て必要な箇所を切り貼りして……という風なことはミスの元になるから、やらない。
    • 複数の異なるバージョンの同じライブラリが同時に入っていても、問題なく動くようにする。
    • という考えで作ったライブラリをリポジトリにまとめてある。
  • 関係ない機能を含めない。コンセプトが合わない機能は、簡単に実装できそうであったとしても、加えない。
    • これはユーザにもメリットがある。
    • 多機能で「とにかく便利」なんてコンセプトだと、ユーザは入れてみるまで薬効と副作用の比較ができない。入れた後も、どれが薬効でどれが副作用なのか分からない。
    • 単機能なら、薬効と副作用を比較しやすい。「この機能はいらないから、入れない」という判断ができる。「よく分からんけどとりあえず入れてみる」という選択を防ぐ圧力が生じる。
      • 多機能にするよりユーザ数は多分減る。でもそれでいい。薬効が必要なくて副作用しか得られない人にまで、使ってもらいたくない。
• 主要な機能を、他のアドオン（自分が作る物も含めて）から使いやすいように「API」として公開する。
  • といっても、物自体は変わらない。あくまでただのメソッド。ただ、作る時の心構えを変える。
    • 自分だけが使うものだから……と思っていると、メンバ変数とかをがんがん使った、実装するのが楽な、結合が密な設計にしてしまいがち。
    • 結合が密だと、100％全ての情報の流れを理解している人間でなければメソッドを使えない。
    • 半年くらいして自分でもすっかり忘れた頃にもう一度見て、すぐに理解できるか？　理解できなさそうなら、それは駄目な設計。
    • 結合をなるべく疎にする。密な結合にしないといけない時は、せめて、情報が双方向に流れないようにする。一方通行に処理を追いかけるだけで理解できるようにする。
  • インターフェースを公開して、ドキュメントも作る。
    • 既に公開してしまっている物だから、安易に変更できないというプレッシャーがかかる。APIの互換性を維持する力が働く。
  • 機能同士の連携は、必ず公開APIを経由して行う。
    • APIでできないことはしない。
    • 必要なら新しいAPIを考える。やっつけ仕事ではなく、ちゃんとした設計で。
• TBEでやってたような、ガチガチの作り込みはしない。
  • 泥臭くてカッコ悪くても、フレキシブルな対応が可能なやり方を取る。
    • XBLでスッキリ書くより、DOMでゴリゴリ書く。
  • なるべく、Firefox自体が持つ構造を壊さない。
    • 要素構造を自分好みにすっかり作り替えてしまえば、自分は楽になる。でも、ユーザが困る。他のアドオン作者も困る。要素構造を変えると他のアドオンと衝突しやすくなる。
  • XBLの使用はできるだけ避ける。
    • 特に、既存のバインディングの「置き換え」は「最後の手段」「禁じ手」と考える。
    • 「まだバインディングが行われていない部分への追加」だったら、使ってもいい。
    • どうしてもXBLじゃなきゃ実現できない、という部分だけに限って使う。それ以外でXBLを使うのは、極論すれば「珍しい技術を使ってる自分」に酔っぱらってる自己満足な行為でしかない、と考える。
  • メソッドを丸ごと置き換える、という事はできる限り避ける。
    • やるのなら、eval()による部分的な書き換えで対処する。
    • やりたいことの大半は、元のメソッドの最初か最後に処理を追加するだけ。メソッドを丸ごと全部別物に置き換えてしまう必要は本来無い。
    • 見通しは悪くなるけど、他のアドオンとの競合は起こりにくくなる。と思う。
    • これによる開発効率・メンテナンス効率の低下は、個々のアドオンを単機能に・シンプルに保つという前提によって相殺する。
• 他のアドオンでできることはしない。
  • 自分一人で抱え込まない。他の人がやってることをわざわざ自分でやり直そうなんてことはしない。
  • 組み合わせて使うことを積極的に推奨する。自分自身も、他のアドオンと組み合わせて使う。
    • 組み合わせて使って問題が起こりにくい設計にしないといけない、という圧力が自然とかかる。

こういう考えに基づいて作ったのが、マルチプルタブハンドラ、情報化タブ、ツリー型タブ、ソース表示タブという4つのアドオンだ。上に書いたことを完全に守れてるとは言えない部分もあるけど、昔に比べれば遙かにマシになってると思う。

作る側としても、使う側としても、僕は今の方がずっと楽だ。

「多機能に」「1つだけで様々なニーズに応えられるように」という方向に頑張ると、縛りがどんどんきつくなってくる。1つのアドオンだけでできることを増やしていこうとすると、妙な話だけど、他のアドオンに頼れなくなっていく。作り込むほどに、そのアドオンを入れた結果が素のFirefoxとかけ離れてしまうから、他のアドオンとの互換性がどんどん失われていく。だから、1つのアドオンだけでしなきゃいけない事がイモヅル式にどんどん増えてくる。

ユーザの視点から見ると、「多機能なアドオン1つだけの世界で完結した使い勝手を享受する」か、「いろんなアドオンを組み合わせて使う」かの、どっちかを選ばないといけないということでもある。両立はできない。

ここで改めて念を押すけれども、僕は、Tab Mix Plusと上記のタブ系アドオンの組み合わせは推奨していない。一応TMPで動くようにはした、けれども、継続的に追っかけ続けるモチベーションが無い。何故なら、僕はTMPユーザではなく、TMPと組み合わせて壊れるようであっても僕自身は全く困らないから。TMPユーザでない他のアドオンの作者の中には、同じように感じてる人もいるんじゃないかと思う。自分が使ってもいないのに対応を迫られるなんて、厄介な奴だ、目障りな奴だ、みたいな。閑話休題。

「多機能なアドオンで、部分的には、痒い所に手が届くような感覚がある。でも、足りない部分もある。それを補うための他のアドオンと組み合わせて使うことは、残念ながらできない。」「単機能のアドオンをたくさん入れていて、それぞれはそれなりに便利。でも、いまいち連携が取れてなくて、痒い所に手が届かない。」そのどっちかを選ばないといけない。

一人あるいは少数の作者の頑張りだけに期待しなきゃいけない、期待して待ってなきゃいけない。多機能長大路線を歩むという事は、ユーザにそれを強いるという事だと思う。僕はそれが嫌になった。

多分、多機能な物を「作る」だけなら、誰にでもできるんだと思う。時間さえかければ。当時の僕にもうなる程の時間があった（大学生で、レベルもそんなに高くなかったから楽に単位を取れて、その分自由に時間を使えた）から、できてたんだと思う。でも、より大きな問題は「作った」の後にあると思う。メンテナンスし続けられるのか？　他のアドオンと協調させられるのか？　多機能長大路線ではそれは難しいと、僕は思った。