Home > Latest topics

Latest topics 近況報告

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

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

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

Page 9/243: « 5 6 7 8 9 10 11 12 13 »

タブをグループ化するためのダミーのタブ(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を整備している。

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

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ユーザでない他のアドオンの作者の中には、同じように感じてる人もいるんじゃないかと思う。自分が使ってもいないのに対応を迫られるなんて、厄介な奴だ、目障りな奴だ、みたいな。閑話休題。

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

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

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

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

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

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

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

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

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

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

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

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

Page 9/243: « 5 6 7 8 9 10 11 12 13 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき