Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 12/241: « 8 9 10 11 12 13 14 15 16 »

Firefox 4のTabs on Topを受け入れられないのは頭が硬直化している証拠 - Jun 28, 2010

タイトルは半分は釣り。

Firefox 4のUIのモックアップでそれが目標として示されて以降、「タブがツールバーの上に表示されるようになる」という変更に対しては色んな人が反対の意を示しているようだ。以下もそのひとつ。

反対意見があまりに多いためか、Mozillaもわざわざ動画まで用意して Tabs on Topの正当性を必死で主張している

この件に関して僕は一貫して、タブをツールバーの上に移動するという決定には賛同している。というか、できる事ならもっと前の時点でそうするべきだったと思っている。今の(Firefox 3.6の)UIのデザインを「この方が優れている」という論調で肯定する意見は、ちゃんちゃらおかしいとしか言いようがない。

何故そう言い切れるかというと、今のUIのデザイン(タブがツールバーの下にある)は、言っちゃあ悪いが、実装者の都合に基づくやっつけ仕事の積み重ねの末にある結果でしかないからだ。Firefoxの前身であるPhoenixが出てくるより前、初めてMozilla本体でタブブラウズ機能を実装し始めた頃から見ていたら、それはもうはっきり分かることだ。

そもそもなんでタブがツールバーの下にあったのかと言えば、それまでのタブが無いUI(Netscape Navigator由来)の中にタブを組み込みつつ、他の部分のコードとの互換性を最大限保つために、変更箇所を最小限にとどめる形で実装が行われたからだ。最初のタブブラウズ機能は、それまで「ブラウズ領域」を確保するために用意されていたbrowser要素(iframe要素の高機能版と思って貰えばいい)と入れ換える形でtabbrowser要素という物を置き、タブに関する変更は全部そのtabbrowser要素の中で完結させるという方向性で実装された。それ以後Firefox 3.6に至るまで、根本的な設計はずっと当時の物を引きずってきた。 (Firefox 3.6までの実装におけるボックスモデルの図)

ここで重要なのは、タブがコンテンツ領域の真上に置かれたこと、ツールバーの下に置かれたことに、ヒューマンインターフェースのデザインの観点からの理由は全く無かったという点だ。理由があってそうしたのではなく、単に「そうするのが実装上簡単だったから」でしかないのだ。

さて、「使いやすい」UIの設計にはいくつかのセオリーがある。

  1. 持って欲しい所は持てそうなように、押して欲しい物は押せそうな形に、見た目を作ること。
  2. 見た目が現在の状態を示すようにすること。
  3. 行う操作と、その結果との関係性を分かりやすくすること。
  4. 他の物に合わせること。

まず第一に、望ましい操作、やって欲しい操作にユーザを誘導するような見た目にするということ。例えば、棒のように突き出た部分があれば人はそれを掴んでみようとするだろう。ぽちっと出っ張った部分があれば人はそれを押してみようとするだろう。見た目は人の行動を誘発する。WindowsでもMac OS Xでもなんでも、ボタンが出っ張った見た目をしているのはそのためだ。

第二に、見た目から状態がすぐに分かるようにするということ。ボタンが「押し込まれた」ような見た目をしていれば、それはもうこれ以上押せないと分かる。オブジェクトの影が他の物の上に落ちていれば、そのオブジェクトが他の物よりも上(手前)にあると分かる。Windows VistaでもMac OS Xでもウィンドウに影が落ちているのはそのためだし、Aero Glassで下のウィンドウが透けて見えるのもそのためだ。

第三に、それを操作したら何が起こるかがはっきり分かるようにするということ。包丁を見たら、取っ手を持って振れば刃も一緒に動く事が分かる。ハサミを見たら、取っ手を握れば刃も動く事が分かる。そういう風に構造が見て取れるものでないなら、何らかの方法で「これを触ったらここがこうなりますよ」って事を分かりやすく示さないと行けない。飛行機のコクピットで着陸脚を操作するためのハンドルがまさに着陸脚そのものの形をしているのは、そのためだ。

最後に、既に似たものがあるのならそれに合わせるということ。今まで使っていたものに似ていればそれだけすぐに使えるし、今まで使っていたものと違っていたらそれだけで操作ミスが増える。自動車のブレーキとアクセルの並び順が、ある車種ではブレーキが左・アクセルが右で、別の車種ではブレーキが右・アクセルが左、なんて事になっていたら、これで事故が起きない方がおかしい。

翻って、今(Firefox 3.6)のタブはどうだろう。

タブ単体の見た目は、悪くない。フォアグラウンドのタブとバックグラウンドのタブはそれなりに見分けやすいし、選択されているタブが他のタブより手前にあるように見えるのも悪くない。押せそうな形をしているし、押せばタブが切り替わる。つまめそうな形をしているし、つまめば並べ替えもできる。

でも、「タブを操作したら何が起こるのか」は致命的に分かりにくい。

  • タブをクリックしたら、タブの上にあるナビゲーションバーの内容と、タブの下にあるコンテンツ領域の内容が変わる。
  • ウィンドウの真ん中あたりにあるタブを閉じる操作をしたら、タブだけでなくウィンドウまで閉じられる。(これなんかは、あまりに酷すぎて僕自身ボロクソに貶しもした。)
  • そもそも、タブが開かれたという事に気づきすらしない人もいる。リンクをクリックしたらボタンっぽい物が1個増えた、でもそれが何なのか分からないし、どうして増えたのかも分からない。

タブをツールバーの上に置くのは、「タブを操作したら何が起こるのか」を視覚的にはっきり示すための一番ストレートで確実な方法なんだ。

とはいえ、今Tabs on Topが非難を浴びているのもまた、上に書いたセオリーの通りではある。「他の物、今までの物に合わせる」ということ。比較の対象は「今のFirefox」に他ならない。

「他の物、今までの物に合わせる」、これは他のすべてを覆しかねないほど重要な事だ。なんだかんだ言って、人は自分の行動を変えようとしないし、今の物と違う物には拒絶反応を示す(上に挙げたそれ以外のセオリーは言わば、「今までの物がどうして使いやすかったのか」を分析する事で、「合わせる」先の既存の物が無い時に新しい物をどう設計するかの指針を示したものと言える)。今までの物に合わせないで別の物を提示するという事には、今までの支持を失うリスクがある。新しい物に絶対の自信がなければ、「今の物と違う」という理由でついて来れなくなる人よりも、新しい物の「分かりやすさ」によって引き付ける事のできる人の数の方が多いと信じていなければ、新しい物は取り入れられない。

要するにMozillaは、今までの支持者を失うリスクよりも、新しいUIで取り込める層の方が多いと見込んだという事だ。あるいは、失った支持者すら、新しいUIの分かりやすさによってもう一度取り込め直せるだろうと見込んでいるのだろう。それだけMozillaは新しいUIに自信を持っているのだろう。

ただ、どうしても受け入れられないという人のためにTabs on Topを無効にするオプションも用意しているあたりが、Mozillaらしいと言えばらしい譲歩ではある。例えばジョブズあたりはこの辺もっと割り切っていて、新しい物を出したら古い物はバッサリ捨てるという風に容赦がない(iMacでのレガシーインターフェース一掃やiPadの有線LAN非対応などはそのいい例だろう)。

まとめよう。

不幸な事にMozillaは、それまであまり知られていなかった「タブブラウズ」という概念を取り入れるにあたって、UI設計のセオリーをまるで無視した実装上の都合からタブブラウズのUIを作ってしまった。

しかし今は違う。メジャーなブラウザはいずれもタブブラウズ機能をサポートし、タブの位置についても、Tabs on Topを採用した例はOperaに続いてGoogle Chromeがある。Firefoxを除けば、タブをツールバーの下に置いているのはIEとSafariだけだ。そしてそのSafariは、タブの連結方向を下ではなく上に向ける事で、少なくともツールバーはタブに従属するものという事を視覚的に示している。採用している実装の数だけを言えば、ツールバーをタブに従属させるデザインの方が多数派になったとすら言える。昔の実装の負の遺産を断ち切るにはそろそろいい頃合いだ。

Tabs on Topに対する非難ははっきり言って、「今までの物と違う」という事それ自体に対する拒否反応でしかない。だから、それを正当化するために「今の配置の方が合理的なんだ」なんておかしな事を言う必要はない。そんな屁理屈を用意しなくても、あなたがTabs on Topを受け入れられない理由は「今までの物と違うから」それだけで十分だ。それは恥ずかしい事じゃあない。「新しい物を作る時はなるべく今ある物に合わせろ」というのが鉄則になるくらいには、人類みな頭が固いんだ。

そして、今までの物を覚えるのに苦労した分だけ「またあんな苦労をして新しく覚え直さなきゃならないのかよ!」と言いたくもなるだろうが、それは杞憂だ。Tabs on Topな新しいUIは、今までの物を覚えるのに要した時間よりもっと短い時間で慣れる事ができる。何故なら、今までタブを使った事がなくてもそのはたらきが見た目で分かる、そういう所を目指したデザインなんだから。

pinTab()、unpinTab()への対応 - Jun 27, 2010

このへんのパッチが投入されて、gBrowser.pinTab()gBrowser.unpinTab()というメソッドが実装された。 (実際に使った所のスクリーンショット) pinTab()にタブを渡すとそのタブが他のタブの左側に寄せられて、unpinTab()に(pinnedな)タブを渡すと元に戻る。ぶっちゃけアレですね、Chromeの似たような機能のパクリですね。

この時、タブはスクロールボタン(左向き三角のボタン)よりもさらに左に表示されるようになるんだけど、これは一体どうやって実現されてるのか。実は、CSSで非常にトリッキーなことをしている。pinTab()に渡されたタブはpinnedという属性の値にvalueが設定されるんだけど、この時、.tabbrowser-tab[pinned="true"]なタブはposition:fixedに設定されて、通常の描画フローから切り離される。その上で、スクロールボックスの左にすべてのpinnedなタブの幅の合計と同じだけのマージンを設けて、pinnedなタブ1つ1つにはネガティブマージンを設定してそれらしい位置に表示する……という感じ。moveTab()の中とかでタブの状態を見て処理を分けていて、pinnedなタブはpinnedじゃないタブの中には移動できないし、その逆も然り。原稿のコードに対する最小限の変更でそれらしい挙動を実現するようにしている。よう思いつくな、こんなの。

大抵の既存のアドオンは影響を受けないはずなんだけど、タブ周りで凝ったことをしてる奴は、下手したら全滅しそうな気がする。というかツリー型タブなんかはお話にならないのが目に見えてる。なのでちょっと頑張ってみた。

  • pinnedなタブのレイアウトの処理。改行とか。
  • pinnedになった時、自動的にツリーから解放するとか。

結果。 (スクリーンショット) 最初は単に、pinnedなタブのレイアウト処理の所のX軸とY軸を入れ換えるだけにしてみたんだけど、それだと縦置きタブバーの場合は無駄な領域がメチャメチャ増えるだけだという事が分かったから、「タブが小さくなる」という所を優先して、24×24固定サイズでアイコンを並べられるだけ並べる(1行に収まらなければ改行する)という風にした。見た目は……あんまり良くないね。すんません。

縦置きしたタブバーとpinnedなタブの相性はすこぶる悪い。結局全部ツリー型タブの方で作り直すのに近い状態になってしまった気がする。でもまあ挙動としてはそれなりに違和感のない状態に落ち着いた。

これからまた実装に仕様変更が入らないことを祈るばかりだ。実装の仕方自体が変わってしまうなら、今回のこの作業はまるっきり無駄になってしまうから。

タブバーの位置を変える方法(How to change the position of the tab bar easily?) - Jun 15, 2010

Q

It is nice if I can switch between tabs on the top and side. I know you can drag it but if the top gets filled up, then its hard to drag it. Then I have to open the prefs to move it. Be nice if it was easier to move the tab bar to different sides quickly.

タブバーの位置を上と左(または右)の間で簡単に切り替えられると便利だと思います。タブバーをドラッグすれば場所を移動できるのは知っていますが、タブバーが上にありタブが沢山開かれていて余白がない場合、タブバーをドラッグするのは難しいです。そういう時は仕方がないので設定ダイアログを使うほかありません。タブバーを異なる位置に簡単に移動できる方法があるといいのですが……

A

I have no plan about (re-)adding the feature to the Tree Style Tab. I think an answer for another question possibly help you: A new option to switch the position of the tab bar by the number of tabs.

By the way, you can start to drag the tab bar without blank spaces in the tab bar. Try to drag something in the tab bar not a tab. (ex. "New Tab" button, "<" button, ">" button, or "List All Tabs" button)

その機能を(再び)ツリー型タブに加える予定はありません。ただ、他の質問に対する回答があなたにとって何らかの助けになるかもしれません。タブバーの縦置き・横置きをタブの数に応じて自動で切り替えたいを参照して下さい。

それはさておき、タブバーのドラッグ&ドロップは、タブバーに余白が無くても行う事ができます。タブバーの中のタブ以外の任意の位置(例えば「新しいタブ」ボタン、スクロールボタン、「タブの一覧」ボタンなど)をドラッグしてみて下さい。

新しいタブを開く時にタブバーの下の端以外の位置に開きたい(How to open new tab not on the bottom of the tab bar?) - Jun 15, 2010

Q

If I open a new tab they always open on bottom. I have alway many tabs open and I need to scroll always down to see new tab. That's for me not very comfortable. Is possible that new tab open on top?

新しいタブを開く時、タブは常にタブバーの一番下に開かれます。私はいつも非常に多くのタブを開いているため、開いた新しいタブを見るためにはいつも一番下までタブバーをスクロールしないといけません。これは非常に面倒です。新しいタブをタブバーの上の端に開く方法はありませんか?

A

Now TST doesn't provide such a feature to control new tab position. I think TST should not implement features not related to "tree of tabs", but it should be done by another addon designed for the purpose, for example, Tab Control does it.

現在、ツリー型タブはそのための機能を提供していません。私は、「タブのツリー」とは関係ない機能はツリー型タブには含めず、そういう目的のために開発された他のアドオンで解決するべきと考えています。例えばTab Controlがそういう機能を持っています。

「xpcnativewrappers=no」の廃止 - Jun 09, 2010

レガシーな仕組みが1つ廃止されたようだ。

XPCNativeWrapperについては過去に行った拡張機能のセキュリティに関するプレゼンの中でも紹介した。現在も既に、chrome権限があるコードからWebページの内容に触る時は基本的には必ずXPCNativeWrapperを介してアクセスしないといけないようになってるんだけど、そういう仕組みがまだ入ってなかった頃の書き方でも拡張機能を書けるように、敢えてこの仕組みをOFFにするための機能があった。それがchrome.manifestでのxpcnativewrappers=no指定。今回上記のbugで投入されたパッチによって、この指定がそもそも機能しないようになった。

XPCNativeWrapper越しでなく生のJavaScriptのオブジェクトにアクセスする方法としては、xpcnativewrappers=no以外にもう1つ、任意のオブジェクトの.wrappedJSObjectというプロパティを見る方法がある。今回投入されたパッチではこの機能までは削除されていないように見えるので、今までxpcnativewrappers=noを使っていた人は、Webページ内のJavaScriptのオブジェクトにアクセスしてた箇所では.wrappedJSObjectを書き加えるようにすれば一応は動くようになるんじゃないかと思う。セキュリティ的には、そもそもラップされてない生のJSObjectに触らなきゃいけないという設計自体を変えた方がいいんだけど。だいたい、XPCNativeWrapperが入ったのってFirefox 1.5がリリースされるよりも前の話だよ。今なおXPCNativeWrapperの存在を前提にしてないコードって、どんだけ古いのさ?

タブのコンテキストメニューが正常に機能しなくなった? (The context menu on tabs doesn't appear anymore?) - May 15, 2010

Q

I'm running your Tree Style Tab extension on the last Firefox, 3.4a. I installed the Menu Editor extension and the context menu on the tabs stopped to appear. Until Firefox 3.6.3 they were working together nicely.

私はツリー型タブを最新版のFirefox(3.7a4)で使っています。Menu Editorをインストールしていると、タブのコンテキストメニューが出なくなってしまいました。Firefox 3.6では両者は正常に機能していたのですが……

A

Codes of the context menu on tabs are totally restructured on the Firefox 3.7a4. See: Bug 554991 - allow tab context menu to be modified by normal XUL overlays. So, addons including codes about context menu on tabs must be updated.

TST newer than 0.10.2010040201 has been updated for the change, but I couldn't find out a version updated for Firefox 3.7a4 from all versions of the Menu Editor.

If the problem still appear with a new version of the Menu Editor updated for Minefield 3.7a4 and later, please tell me again.

タブのコンテキストメニューの実装は、Firefox 3.7a4で大きく変わりました。Bug 554991 - allow tab context menu to be modified by normal XUL overlays を参照してください。このため、タブのコンテキストメニューを触るアドオンは更新されなくてはなりません。

ツリー型タブのバージョン0.10.2010040201以降はこの変更に対応済みですが、私はMenu Editorの公開済みのバージョン一覧からMinefield 3.7a4に対応したバージョンを見つけることはできませんでした。.

もしMenu EditorのFirefox 3.7a4対応版がリリースされた後でもまだ問題が再現するようであれば、改めてご連絡ください。

一言でいえば、「Firefox 3.7a4の新仕様にきちんと対応してないアドオンと組み合わせて何が起こっても僕の責任じゃないですよ」ってことで。

「タブを閉じる」ボタンの働きの選択肢として「親のタブを閉じずに子孫のタブだけを閉じる」が欲しい(A new option to close only child tabs by "Close Tab" button) - May 14, 2010

Q

My small suggestion is to be able to configure the close button for a parent tab to just close its children. After it is child-less, the second click would close the tab itself. My feeling is that this would make for more fluid experience when you open up a flurry of child tabs to follow up on details and want to continue with the main "story" or "task" on the original parent tab. As it is now you have to right click and select close children, which I find a bit clunky.

私の希望は、親のタブの「タブを閉じる」ボタンをクリックした時の挙動として、子孫のタブだけを閉じるというオプションが欲しいというものです。そのタブに子供がいなくなった後、2度目のクリックはそのタブ自身を閉じるでしょう。これがどういうときに役立つかというと、何か作業をしている時に、詳細な情報を見るために子タブをいくつか開いた後で、それらを一気に閉じて元の作業に戻るという風な場合です。現状でこのような使い方をするには、タブを右クリックして「このタブの子タブをすべて閉じる」を選択しなくてはならないので、面倒です。

A

Sorry, I have no plan to implement the feature to Tree Style Tab. There are two reasons: 1) overriding of the behavior of "close tab" button is hard to implement. And, 2) I think it is not an instinctive behavior.

1) Now there are some options for "close tab" of parent tabs, but all options are designed to work just after the parent tab was correctly closed. Because, TST listens "TabClose" event which is fired after the tab is completely closed by Firefox itself. We cannot cancel the closing of the parent tab from "TabClose" event.

2) If "close tab" button closes the tab and its collapsed children, I think it is instinctive, because it is same to the default behavior of the "close tab" button, except there are collapsed (hidden) children. And if the button closes only the parent tab (keeping children open) it is also same to the Firefox default. "When the close button is clicked, only children are closed and the tab itself is still there" -- the scenario is odd a little for me.

However, you can implement the feature with other scriptable addons (FireGestures, userChrome.js, etc.) with following codes:

var parentTab = gBrowser.selectedTab;
if (TreeStyleTab.hasChildTabs(parentTab)
  // The second argument "true" means "close only children".
  TreeStyleTabService.removeTabSubtree(parentTab, true);
else
  gBrowser.removeTab(parentTab);

すみませんが、その機能をツリー型タブ本体に取り込むつもりはありません。それには2つの理由があります。1) 「タブを閉じる」ボタンの挙動を乗っ取るのは実装が大変ですし、2) その挙動は直感的とは私には思えません。

1) 現在、親のタブの「タブを閉じる」ボタンをクリックした場合の挙動にはいくつかの選択肢を設けてありますが、そのいずれも、親のタブ自体が閉じられた後に働くことを前提にしています。これはツリー型タブが、タブが完全に閉じられた後でFirefox自身によって発行される「TabClose」イベントを監視することによってこの機能を実現しているためです。「TabClose」イベントからは、タブを閉じる操作自体をキャンセルする事はできません。

2) 「タブを閉じる」ボタンによってそのタブ自身とすべての折り畳まれた子タブが閉じられる場合、そこに折り畳まれた(見えない)子タブがあるという点を除けばFirefoxの標準的な挙動と同じなので、これは私には直感的な挙動に感じられます。また、もしそのタブだけが閉じられて子タブが残るのであれば、これはFirefoxの標準的な挙動と全く同じです。しかしながら、「タブを閉じるボタンをクリックしたら、子タブだけが閉じられて、そのタブは已然として開かれたままとなる」――この挙動は、私には違和感があります。

とはいえ、あなたはこの機能を、スクリプトでカスタマイズする機能を持った他のアドオン(FireGestures、userChrome.jsなど)と組み合わせる事で実現できます。上記のコードを参照して下さい。

ロケーションバーからAlt-Enterでタブを開けない?(ALT-Enter in the location bar doesn't open new tab?) - May 14, 2010

Q

In plain Firefox, ALT-Enter in the address bar opens a new tab. This doesn't happen with Tree Style Tab activated.

素のFirefoxでは、ロケーションバーでAlt-Enterと入力すると新しいタブが開かれます。ツリー型タブが有効な状態だと、この機能が働きません。

A

I think it is a designed behavior of TST. TST includes a feature to open new tabs from the location bar without the ALT key, and the effect of the ALT key is inverted by the feature (Enter => new tab, ALT-Enter => current tab).

To get back Firefox's default behavior (Enter => current tab, ALT-Enter => new tab), go to TST's configuration dialog => "New Tabs" => "Location Bar".

If you don't want any loading into the current tab from the location bar (Enter => new tab, ALT-Enter => new tab), then, go to about:config and turn "extensions.treestyletab.urlbar.invertDefaultBehavior" to "false".

この挙動はツリー型タブの仕様であると思われます。ツリー型タブはロケーションバーでAltキーを押さずに新しいタブを開くための機能を含んでおり、この影響によって、Altキーの働きは反転される事になります。(Enter→新しいタブ、Alt-Enter→現在のタブ)

Firefoxの既定の挙動(Enter→現在のタブ、Alt-Enter→新しいタブ)に戻すには、ツリー型タブの設定ダイアログで「新しいタブ」→「ロケーションバー」を参照して下さい。

もし常に新しいタブを開くようにしたい(Enter→新しいタブ、Alt-Enter→新しいタブ)場合は、about:configを開いて extensions.treestyletab.urlbar.invertDefaultBehavior を false に設定して下さい。

Windows 7のAeroPeek(タスクバーのプレビュー)にアドオンから手を出してみる - May 13, 2010

Windows 7では、特定のアプリケーションのウィンドウが複数開かれている状態でタスクバー上のボタンをポイントすると、各ウィンドウのプレビューが一覧表示されるようになっている。これはAero Peekという機能だ。Firefox 3.6以降ではこのAero Peekのためのコードが入ってて、about:configでbrowser.taskbar.previews.enableをtrueに変更して機能を有効にすると、ウィンドウごとではなくタブごとのプレビューが表示されるようになる。Trunkではデフォルトで有効になってるので、次のメジャーリリースでもそうなるんだろう。

この機能について、ツリー型タブで対応してくれという要望が何件か来ていたので、0.10.2010043001以降では折り畳まれたツリーの中にあるタブのプレビューは表示しないようにしてみた。これを実現するにあたって調べたことを書き記しておく。

FirefoxでウィンドウごとではなくタブごとのプレビューをAero Peekに表示させるためのコードのうち、アドオンから簡単に触れるのはWindowsPreviewPerTab.jsmにあるコードだ。以下のようにするとプレビューのマネージャにアクセスすることができる。

Components.utils.import('resource://gre/modules/WindowsPreviewPerTab.jsm');
alert(AeroPeek); // "[object Object]"

ツリー型タブの新機能(?)の「折り畳まれたタブに対応するプレビューを隠す」は、ここからどうやれば実現できるのか。

まずAeroPeek.windowsの中から、処理対象のウィンドウに対応する項目を探す。このプロパティは各ウィンドウに対応するオブジェクトの配列になっていて、オブジェクトのwinプロパティにFirefoxのブラウザウィンドウのDOMWindowオブジェクトがそのまま入ってる。なので、以下のようにすれば今のウィンドウに対応するオブジェクトを見つけられる。

AeroPeek.windows.some(function(aTabWindow) {
  if (aTabWindow.win == window) {
    // 現在のウィンドウに対する操作
    return true;
  }
  return false;
});

また、このオブジェクトはpreviewsというプロパティの中に各タブのプレビューに対応するオブジェクトを持っている。以下のようにすれば、プレビューからタブのDOMElementを辿ることができる。

aTabWindow.previews.forEach(function(aPreview) {
  var tab = aPreview.controller.wrappedJSObject.tab;
  // タブに応じた操作
});

プレビューのオブジェクトはvisibleという真偽値のプロパティを持っていて、これの値がtrueだとAero Peekのプレビューが表示され、falseだと非表示になる。ツリー型タブの場合、タブが折り畳まれているかどうかによってこの値を上書きするようにしている。

var tab = aPreview.controller.wrappedJSObject.tab;
aPreview.visible = !TreeStyleTabService.isCollapsed(tab);

初期状態では、visibleの値はbrowser.taskbar.previews.enableの値と同じになっている。アドオンでvisibletrueにするとユーザがAero Peekを設定で無効化してても問答無用でプレビューが表示されてしまうので、誤ってtrueにしてしまわないように気をつけないといけない。僕はうっかりこれをやってしまった。

で、プレビューの表示・非表示を切り替えた後は、表示されるプレビューの総数が変わったことをマネージャに通知してやる。

AeroPeek.checkPreviewCount();

Firefoxは、プレビューの数が多すぎる時は強制的にプレビューを非表示にするようになってる。その切り替えの判断は、このメソッドが呼ばれた時に行われている。

以上をまとめると、こうなる。

AeroPeek.windows.some(function(aTabWindow) {
  if (aTabWindow.win == window) {
    aTabWindow.previews.forEach(function(aPreview) {
      var tab = aPreview.controller.wrappedJSObject.tab;
      aPreview.visible = !TreeStyleTabService.isCollapsed(tab);
    });
    AeroPeek.checkPreviewCount();
    return true;
  }
  return false;
});

ツリー型タブでは、これをツリーの開閉が行われる度に実行している。開閉の捕捉はカスタムイベントで行ってる。

プレビューの並び順とかも変えれそうな気がなんとなくしてるので、やる気が出てきたらまたいじってみようと思ってる。ただ、他のアドオンもここに手を出すと衝突しまくりそうではある。

Page 12/241: « 8 9 10 11 12 13 14 15 16 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき