Latest topics 近況報告

ウィンドウにフォーカスするとタブの色が変わる（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.

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

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

ツリー型タブとVimperatorが衝突する - Apr 14, 2009

という報告を受けて調べてみて、解決策が見えなくて頭を抱えてる。

原因はFirefox 3以降でタブの拡張性が深刻なまでに低下したことに起因している。現在、Firefox 3でタブの中に独自の要素（ツリー型タブの「ツリーの開閉状態を示すアイコン」「折り畳まれたタブの数を表示するラベル」など）を追加しようとすると、バインディングを上書きしてやらないといけない。でも複数のアドオンでバインディングを上書き上書きとやってると、最後にバインディングを適用した誰かの物だけが生き残って、他のアドオンが追加したバインディングは全滅してしまう。今回の問題も、ツリー型タブがFirefox自身の提供するバインディングを上書きした後から、Vimperatorがさらにバインディングを上書きしているために、タブの要素構造がツリー型タブが想定する構造から変化して、初期化に失敗するようになってしまっている。

ツリー型タブ、マルチプルタブハンドラ、情報化タブの3つを開発するにあたっては、この問題に対処するために、以下のような方針をとることにした。

• それぞれが別個にバインディングを適用したら、お互いに主導権の奪い合いになる。
  • だから、適用するバインディングは「タブの中に要素を追加できる状態」を整えるためだけの物にする（三者でそれを共有する）。
    • その時の「タブの中に要素を追加できる状態」は、Firefox 2以前のバインディングと互換性がある物にする。
• タブの中への要素の追加は、タブが追加された時のTabOpenイベントを拾って、スクリプトで動的に行う。

これを実現するために作ったのがこちらのライブラリ。3つのファイルで構成されてる。

• tabFx2Compatible.xul
• tabFx2Compatible.xml
• tabFx2Compatible.css

3つを同じ所に置いてXULファイルだけをオーバーレイで読み込ませると、バインディングを上書きする。他のアドオンで同じライブラリが読み込まれてる時は、最新の物が使われる。

これをVimperatorの作者の人にも使ってもらえればいいんだけど……誰にコンタクトすればいいか分からないし、そもそも向こうにはわざわざこれを使う動機がない。Vimperatorユーザは基本的にVimperatorのカスタマイズですべてを解決する傾向にあるようだから、他のアドオンとの互換性が低くても問題にならないだろうし。

ていうか僕自身Vimperator使ってないから、わざわざ上記のような交渉をしようというモチベーションがない。というわけで、上に名前が出てる3つのアドオンのどれかとVimperatorとを共存させたいVimperatorユーザの人は、自分で作者にコンタクト取ってください。（丸投げ）

アニメーション効果を有効にしたツリー型タブの新版とデモ動画を公開したよ - Apr 09, 2009

Tree Style Tab 0.7.2009040901公開した。アニメーション効果の実装の他に、細かいバグ修正も色々。

あと、実際どんな感じかというのをわかりやすく示せるかなと思って、デモ動画も作ってみた。CamStudioもNiVEも使うの久しぶり（っていうかVistaにしてからは初）だから、やり方思い出すのに苦労したよ……

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/M9dUfyoHz3E&hl=ja&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/M9dUfyoHz3E&hl=ja&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

ヌルヌル動いてるのは倍速再生してるわけではなく、これで等倍速です（一応）。タブの影はbox-shadowで描画してるので、Firefox 3.0.xだと影無しになります。

しかしYouTubeはアップロードが簡単になってるわ画質が上がってるわで、いつの間にかすんげーパワーアップしてますね。Stage6とかあった頃とは隔世の感があります。

以下余談。

実装の最後の段階になって困った点として、画面外にタブが開かれた時にそこまで自動スクロールしてくれないという問題が起こってた。スクロールしても、新しく開かれたタブの一個前のタブの位置にスクロールしちゃったりして。上の動画で言うと、0:57あたりで画面下の方でサブツリーを展開した時に、子タブが画面内におさまるように自動でスクロールしてるけど、これがちゃんと動かなくなってた。

なんでこんな問題が起こってたかというと、「そのタブが画面外にあるのかどうかを判定する」「そのタブの位置までスクロールする」といった処理が全部「タブの座標」を基準にしてたせいで、アニメーション開始時点やアニメーション中の中途半端な座標を元に処理を行ってしまい、もうシッチャカメッチャカになってた、という……

上記の処理を行う時に、アニメーション中の座標とアニメーション終了後の座標とのズレをきちんと考慮して計算してやればいいってだけの話なんだけど、普通に考えるとこれがめんどくさい。それぞれのタブがちょっとずつズレて表示されてるわけだから、座標を調べたいタブだけじゃなくてそれより前（上）にあるタブ全部について、そのタブはアニメーション中か？とか、そのタブは非表示か？とかを判別しながらオフセット値を調べないといけないわけで……いちいちそんな計算するのはめんどくさすぎる。メンテナンスし辛そうだし、コードの量が多くなりそうだし、真面目に書く気しないです（大学生の頃だったらやってたかもだけどね……時間は有り余ってたから）。

で、代わりに以下のようなやり方を思いついた。

• アニメーション開始時点やアニメーション実行中は、個々のタブの属性値として本来の座標からのオフセット値を持たせておく。
• タブの座標が必要になった時には、「特定の条件にマッチするタブの当該属性値を収集して合計した値」をXPathで取得して、それを現在の座標に足してやる。

コードにするとこんな感じ。

getYOffsetOfTab : function(aTab)
{
  return document.evaluate(
    'sum((self::* | preceding-sibling::*[not(@tab-collapsed="true")])'+
         '/attribute::tab-y-offset)',
    aTab,
    null,
    XPathResult.NUMBER_TYPE,
    null
  ).numberValue;
},

sum()は、渡されたノードセットの値を数値として合計したものを返すXPathの関数。受け取る結果の型をXPathResult.NUMBER_TYPEと指定すれば、計算結果の数値を直接得られる。XPathはうまく使えばこんな風に、処理対象のノードの絞り込みだけじゃなくその後の処理（ここでは計算）まで一発で済ませられるので面白い。

ツリー型タブにアニメーション処理（トゥイーン）を加えつつある - Apr 08, 2009

以前、ツリーの折りたたみでアニメーションするようにしてみた事があった。

この界隈には、GUI要素のアニメーションは嫌いで片っ端から無効にしてて、Web上でもアニメーション効果が使われてると「ウザッ」と思う、というタイプの人が多そうだと思う。でも、アニメーション効果ってのはインターフェースの見た目を考える上で結構バカにできない。

現状のように一気にすべての子タブが出たり消えたりすると、「最初の状態」と「最後の状態」の差が大きすぎて、今自分がどのタブを見ているのか見失ってしまう事がある。でもアニメーションで少しずつ折りたたんだり少しずつ展開したりする事で、「最初の状態」と「最後の状態」の間を段階的に変化させてやると、それほど戸惑わなくて済むようになる。こういう、2つの状態の間を埋めるアニメーションのことを一般にトゥイーンと呼ぶ。使い所を間違えなければ、アニメーションするインターフェースは人にやさしいものとなる。

問題は、再描画が頻繁にかかるのでPCの性能次第では激重になってしまうということ。以前試した時も、自分の環境でとんでもなく重い結果になってしまったので、導入を諦めてた。

で、今日ふと思い立ってもう一度試してみたところ、VistaのAeroが快適に動くような環境ではさすがに快適に動作してくれることが分かった。上記のような小難しい理屈を抜きにしてもヌルヌル動きまくりなのが単純にスゲー面白い。今回はかつて諦めた時のようなフレーム数固定（何回描画したら終わり、というやり方）ではなくフレームレート可変（何秒以内にできる限りの回数だけ描画する、というやり方）で処理するように実装してみたので、貧弱な環境でもそれほど重くはならないと思うんだけど……一応会社のマシンとかで試してみて、問題なさそうなら次版でデフォルト有効にしてみようと思う。

ここでは折りたたみのトゥイーンについてだけ書いてるけど、今回最初に取り組んでたのは元々はインデント幅の変更部分のトゥイーンだった。インデント幅の調整くらいだったらそれほど負荷は高くないだろう、という考えでやり始めたんだけど、最終的には折りたたみまで含めてアニメーション化しても結構気持ちよく動いてくれたということで、上のような話になっている。

面白い副作用として、インデント幅の調整と「折り畳まれたタブを元の状態に戻す」処理とが同時に走ると、まるで画面の左上からその位置にタブが落ちてきて填り込むようなエフェクトになる事に気がついた。どこにタブが増えたかを見失いにくくなる、という効果があるんじゃないかと思う。また、Vista＋Aeroだと割となんでもアニメーションするので、その中に結構馴染んでる気もする。

追記。Let's note W7のUbuntuだと、Shiretokoだとわりかしヌルヌル、Firefox 3.0.xだとフレーム落ちで単純にアニメーションしてないように見えるだけという感じ。ドスパラのWindows XPマシンでも同じような感じだった。コマ落ちした場合でも最低1回は再描画があるので、ワンテンポ遅れる感じはあるんだけど、アニメーションしてる間反応がなくなるという風なことはないので、とりあえず次版から有効にしようと思う。（無効にする設定はもちろん付ける）

Mac OS Xのデフォルトテーマに合わせた新スタイルをツリー型タブに加えたよ - Mar 26, 2009

Tree Style Tabで選択可能な組み込みのスタイル指定の一つとして、Mac OS X上のデフォルトテーマ風の物を、cho45さんのStylish用スタイル定義を参考にして作ってみた。 スクリーンショットはVista上での物だけど、OS X上でも確認はしてるのでご安心を。

Firefox 3以前の環境ではcho45さんのスタイル定義ほぼそのまんまを適用するようになってて、その場合はタブの高さが26ピクセル固定になってしまうのでタブの中に何か追加する系のアドオン（具体的にはInformational Tab）との相性が非常に悪い。

で、それをなんとかする方法として、Firefox 3.5以降ではborder-imageが使えるということを思い出したので、その実験というか練習も兼ねて使ってみる事にした。

普通に考えると、tab要素自体に-moz-border-imageを指定すればそれでおしまいという事になるんだけど……ツリー型タブの場合はドロップ位置のマーカーを表示するためにborderを多用してるので、-moz-border-imageをtabに指定すると都合が悪い（普通のborderと同時に指定した場合、-moz-border-imageの方が優先されるようだ）。かといって、内側や外側にもう一つタブ全体を囲うXUL要素を増やそうとすると、他のスタイル指定と激しく競合して見た目がグチャグチャになるし……

で、色々試行錯誤して、Firefox 3以前でタブの右・左・中央のそれぞれに異なる背景画像を表示するために使っていたボックスを流用して解決する方法を思いついた。

この拡大図で言うと、9個に分けられた各領域を普通だったら一つのボックスのborder-imageでカバーするところを、今回は1～3・4～6・7～9の3つのボックスに分けている。-webkit-border-imageや-moz-border-imageの例として紹介されているコードでは4つの辺の幅を同じにしてる例が多いけど、実は4つの辺はそれぞれバラバラに幅を指定できる。なので、

• 図の赤のボックスはurl("共通の画像") 10 10 10 10 / 10px 0 10px 10pxで右の辺の幅を0に。
• 緑のボックスはurl("共通の画像") 10 10 10 10 / 10px 0 10px 0で左右の辺の幅を0に。
• 青のボックスはurl("共通の画像") 10 10 10 10 / 10px 10px 10px 0で左の辺の幅を0に。

という風にしてやる事で、1枚の画像で3つのボックスそれぞれに異なる部分を切り出して適用するような効果を得られる。

また、このままだとタブの高さがborder-imageの幅の分だけ高くなってしまう（border-imageの上辺＋タブのラベルの高さ＋border-imageの下辺＝タブの高さ）ので、タブのラベルやアイコンなどに対して上下にネガティブマージンを設定して、強制的にタブの高さを小さくするようにしてみた。上の図は切り出し位置を示すためにわざと高さを広げた状態だけど、ネガティブマージンを効かせれば、冒頭のスクリーンショットのようなスリムなタブになる。

ツリー型タブがおすすめされた結果がご覧の有り様だよ！ - Mar 17, 2009

Mozilla Fluxでとりあげてくれてるけど、ツリー型タブがAMOのスタッフおすすめリストに載った模様です。

ちょっと前にメール来てたけどよく分かんなくて放置してたけど、Mozilla Fluxの記事に色々詳しい情報があったんで「へーそういうことなのかー」と思って統計を見てみたら、ダウンロード数爆増してて吹いた。 前述のメールが来てたのが3月頭で、グラフが飛んでる所がそれ。それまで一日数百件のダウンロードだったのが、10倍くらいに跳ね上がってる。

だからというわけでもないわけでもないんだけど、昨日更新した。久しぶりにAMOの方のレビューを見てみたら「これに対応してくれ」というアドオンの名前がいくつか挙がってたので、それへの対応。あと前回エンバグしてた部分の修正。

ツリー型タブ on Vista - Mar 05, 2009

そういえばbox-shadow（-moz-box-shadow）が使えるんだったなと思って、Firefox 3.1……じゃなくて3.5以降ではツリー表示したタブに影を付けるようにしてみた。

「新しいタブ」ボタンの影だけは背景画像です。