Home > Latest topics

Latest topics 近況報告

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

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

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

Page 1/248: 1 2 3 4 5 6 7 8 9 »

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

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

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

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

危険なアドオン、悪意あるアドオン、低品質なアドオン - Dec 05, 2008

FirefoxでAmazonの商品ページを見た時に違法ダウンロードのリンクを自動挿入するという、倫理的に宜しくないアドオンの話のコメントでタブブラウザ拡張の話が引き合いに出されていたので久しぶりに読み返してみた。

ああ、懐かしいなあ。こんな時もあったなあ。

この時はTBEが叩かれてTabMixが祭り上げられてたけど、今となってはTabMixPlusがこの時のTBEと同じような叩かれ方をしてる(TMPがアップデートされるまでFirefox 2から3に移行できない、とか、ロックインのような状態も発生してる)というのは、性格の悪い僕としては「ざまみろプギャー」と思わずにはいられません。

あの頃と状況が変わった点と言えば、当時はリリース版よりナイトリービルドの方を使うようなマニアな人の方が多かったから毎日のようにTBEが本体の変更の影響を受けてマトモに動かなくなって大問題になってたけど、今ではリリース版を使う人の方が多くてその手の「昨日は動いたのに今日はもう駄目になってる」という事態が発生することが減ったことと、あと、わりかしザル気味とはいえAMOのチェック機構のおかげで、入れた瞬間に必ずクラッシュするようなひどいアドオンにぶち当たることが少なくなったこと、あたりがあるでしょうか。他にも、Mozilla自体の作りがだいぶマシになって余計な危険なことをしなくてもよくなったとか、MDC等でドキュメントが充実してきて平均的な技術レベルが向上したとか、そういうのもあるのかも。

僕個人についても、自動テストを導入し始めたとか、他のアドオンとなるべく衝突しなくてすむようなやり方を色々考えるようになったとか、色々変わったとは思う。

しかしこういう(悪意有るアドオン云々の)話題だったらむしろ、以前にプレゼンしたCドライブを強制的にフォーマットするようなヤバイ拡張機能の話の方が適してるような気もするんだけど。でもこの時のはプレゼン資料しか公開してないんだよなあ。これだけ見ても意味分からんか。

About Tabbrowser Extensions - Feb 04, 2008

Hello, thank you for your mail.

The only problem now is the new version, the old one for Firefox 1.5 is a lot better and right now I prefer having Firefox 1.5 with your old extension instead of using the new one.

Have you thought of making the same as for 1.5? If not, will you do it?

Currently I have no plan to develop an extension same as TBE on Fx 1.5. I suffered from too many bugs which are from options I didn't use, so, I decided to keep developing "TBE3" only on features I really need.

Because I was a student and I had a lot of off-time, I could develop huge software like old TBE. But now I'm one of working people. There is less time and motivation.

Now there are nice projects, Tab Mix Plus and Tab Kit, suites of tabbed browsing features. And, userChrome.js is also available to make people's small requirements reality. Lots of people develop user-scripts for the extension on MozillaZine forum. I hope communities of those extensions help you.

regards,

タブブラウザ拡張3 - Dec 06, 2007

TBEのページのトップを刷新して、古い情報は別のページに移動した。どれだけの人がこのページを今も利用してるのかは微妙な所だけど、Firefox 2向けの情報が注意書きとしてだけ入ってるというのは現状からするとあまりよくないので。

「タブ」というUIの一歩先 - Nov 18, 2007

先日、ツリー型タブのアピール文を英語で書くために人の手を借りながらああでもないこうでもないとやってるうちに思ったことなんだけど。図らずも、大学の卒業制作でやったWeb Mapで実現したかったことの一部を、僕はツリー表示とサムネイルによって手に入れていたようだということに、今頃気がついた。

タブのツリーは、今まで「ページ同士の関係性が分かる」という風に説明をしてきた。でも、実際にもたらされる効果の面から言い換えると、「あるページを基点にした閲覧の足跡をそのまま、興味が移り変わっていく様子=ツリーの分岐という形で保持し、好きな時点の興味の対象の間を容易に行ったり来たりできるようにする、視覚的な履歴」ということになると思う。

デスクトップ百景のスクリーンショットを見ての通り、僕はタブをたくさん開く方だと思うけど、べつに、多数のページを本当に平行して見ている訳ではない(そんな聖徳太子みたいなことはできない)。実際には、「後でもう一回読み返そう」「後でコメントしよう」「後で日記のネタにしよう」そう思った物を「読みかけ」「保留状態」で置いたままになっているだけだ。

そういう用途だったらブックマークを使えばいいじゃないかと言われるかも知れないけど、僕にとってはそれでは駄目なんだ。ブックマークはフォルダに放り込んでしまったらもう見えなくなる。画面がスッキリしていいんだけど、それはつまり意識の外に行ってしまうということで、「どこに何がある」ってことをちゃんと記憶しておかないとすぐに忘れてしまう。ソーシャルブックマークもそうだし、同様の理由で多分僕にはRead it Laterも使いこなせないと思う。

でもタブは、明示的に閉じない限りは視界の隅に残り続ける。他のことをし終わって一息ついた時、「ああ、そういえばこれがまだ未処理だった」という風に自分から主張してくる。そういう未処理のがスクが溜まって、タブがどんどん増えてくると、タブバーがだんだん狭苦しくなってきて、「ああ、そろそろ片付けなきゃな」って気になってくる。

ウィンドウ上部に水平に置かれたタブでは、勝手が悪い。たくさんタブを出そうと思ったら、一つ一つのタブが小さくなりすぎて何のタブだったかが分からなくなるし、タイトルが読めるような大きさでタブを表示すると、1画面の中に数個しかタブが表示されなくなる。これでは、自分のしていたことをざっと俯瞰することができない(「タブの一覧を表示」ボタンもあるにはあるけど、「モード」の切り替えを必要とするので、僕には馴染めない)。ある程度の情報を表示できる状態のタブを、10とか20とか表示できるのは、ウィンドウ左右での「縦置きタブ」ならではの利点だ。

単にタブを縦に並べただけでも不十分だ。確かにさっきは「自分のしていたことをざっと俯瞰できないから嫌だ」と書いたけど、でも、していたことの子細が全部一度に見える必要はない。全教科のノートの全ページを並べて見せられるより、それぞれのノートの表紙だけ並べて見せられた方が、余計な情報が少なくて、「ざっと見る」という目的に即しているだろう。そういう意味で、それぞれのツリーを折り畳んで、各ツリーの基点になった「親」のタブだけをざっと眺めることができるツリー型タブは、先ほどのノートの例え話にも似た効果がある。

こういう使い方をするにあたっては、それぞれの「タブ」が含んでいる内容を常時見ることができるようになっていると、なお良い。情報化タブでモードレスに常にサムネイルを見えるようにしているのは、そういうことだ。

最近仕事でRuby on Railsをやらないといけなくなって、MVC(データと、その表現形式と、制御)をきちんと分離するという考え方に今頃になって触れた。確かにプログラムを作る時はそれらは分離した方がうまく行きそうだけど、ユーザの目に見える時にはそれらが一体になっている方が多分いい。レバーを上げ下げすれば「操作できる」と同時に「データ(状態)が変わり」、さらには「今の状態が表現される」、という風に、原始的なUIはMVCが一体になっているからとても分かりやすい。プログラムを作る段階では構成要素ごとにMとVとCに分解しても、その後、それをユーザに見せる時にはもう一度統合するということが必要なんじゃないかと思う。

Ubuntu 7.10にアップグレードしてみた - Oct 28, 2007

仕事で使っている環境は、ずーっと昔に導入したときの6.06 LTSで、早いとこ新しいバージョンに乗り換えたいなあと思いながら今までずるずるとDapperのまんまでいた。乗り換えずにいた理由の一つに、以前会社で訳もわからんままに使わされていたDebianのWoodyからSargeへのアップグレードの時に色々大変でもうこんなのはたくさんだと痛感させられたから、というのもあったんだけれども、まあ最大の理由はタブブラウザ拡張

TBEはFirefox 1.5までにしか対応してなくて、そのFirefox 1.5が今年の6月でMozilla側のサポートが終了してしまったのでセキュリティホール放置で激ヤバ極生! 早いとこFirefox 2に移行しなきゃ! と考えるのが正常なユーザなんだけれども、名前が「LTS(Long Time Support)」と付いているだけあってUbuntu 6.06のデスクトップ環境は(アプリケーションまで含めて)長期のメンテナンスが約束されていて、コミュニティ(どっちかというとUbuntuよりDebianコミュニティ?)がセキュリティアップデートを提供し続けてくれてたんで、Ubuntuを使ってる限りはFirefox 1.5でもまだ一応安心して使い続けることができる。という状況があったので、Firefox 2に乗り換えないとねという強制力もなかなか働かないし、じゃあTBEも今のまんまで自分は困らないし、という感じでTBEのFirefox 2対応は遅々として進まなかった、というより全然手つかずのまま放置してたと言っていい。

逆の方向から見ても、自分自身のWebの利用が完全にTBEに依存しているので、TBEが使えなくなって不便になるというデメリットとFirefox 2に乗り換えることで得られるメリットとを単純に天秤にかけても前者の方が圧倒的に重い。だから、Firefox 1.5で居続けることが許されるのであればいつまでもFirefox 1.5で居続けたいし、ということはUbuntuのバージョンも上げたくない(Linuxのディストリビューションのアップグレードでは入ってるアプリケーションまで全部ひっくるめてアップグレードされるので、Ubuntuのアップグレード=Firefox 2への乗り換えとなる)し上げられない。

ちなみに、Operaとか他の奴に乗り換えれば?と思う人もいるかもだけど、Operaにはちょっとした恨みがある(といってもそんな大層なことではなくて、このページを以前のバージョンのOperaで開いたらクラッシュするだの表示が崩れるだのの問題が多発して、CSSの仕様に則って書いたとおりの物をCSSの仕様通りに解釈できないOperaキモス!! と思ったというだけのことです)し、他の奴にしても、使い勝手等で不満を感じた時に自分でどうにかできる余地が残されていないものを使うのは、なまじっかそれが「できる」環境に一度どっぷり浸かってしまった以上、もう考えられない(ああ、なんかGNU教に嵌ってる気がする……)。

……というのが、2007年も末が近づいてきたこの時期になって未だにFirefox 1.5でUbuntu 6.06という環境を使い続けていた経緯です。

でも最近、やっぱりどーしてもFirefox 2に移行しないといけないという事になってしまいまして。これはもう切羽詰まっててヤバイぞ、いよいよ年貢の納め時だ、ということでツリー型タブをたった4日の超特急突貫工事で作った、と。

自分がTBEで「これだけはなくなると死んでしまう!」と思っていた機能をFirefox 2に持ち込むことができたので、Firefox 2への移行もアッサリ済ませることができて、じゃあせっかくだからUbuntu自体も最新バージョンにアップグレードしてしまおうか、と思ってやってみたわけです。

続きを表示する ...

タブブラウザ拡張3 - Oct 27, 2007

タブブラウザ拡張3を公開しました。

……といっても実際にタブブラウザ拡張のバージョン3を作ったわけではなくて、情報化タブマルチプルタブハンドラツリー型タブソース表示タブ以前訳したマルチアイテムパッケージの作り方のまんまで一つにパッケージングしただけですハイ。「TBE3」をインスコすると上記4つのアドオンがアドオンマネージャに普通に並びます。

まあ、色々要望等はあると思うけど、僕にとってはこれだけ揃ってたら「TBE3」と名前を付けてもべつにいっかなーと思えている、僕にとっての「タブブラウザ拡張」の「他では替えが効かないもの」はこういう事かな、という感じです。

僕自身はこれに加えて以下のアドオンを組み合わせて、旧TBEで使ってた操作感をなるべく再現して使ってる。

  • Undo Closed Tabs Button:閉じたタブを一覧からすぐに開き直せるように。(複数のセッションの管理は実際の所あんまり使ってなかったんで……セッション管理もしたい人はSession Managerあたりをどうぞ)
  • Tab Clicking Options:タブバー上でのダブルクリックで新規タブ、タブバー上での中クリックで閉じたタブを復元、という操作をするため。それ以外の機能は使ってない。
  • Adaptiva Referer Remover:127.0.0.1とかlocalhostとかからのリファラ送信をカットするために。

逆に、TBEが持ってた機能で今の環境(他のアドオンとの組み合わせも含めて)に欠けてるのは、タブの複数行表示、タブの色分け、フォーカスの詳細な制御、タブのロック、自動リロード、別サイトへのリンクを常に新規タブで開く(別サイトへのリンクをタブで開く機能はツリー型タブ 0.3.2007102902に実装した)リファラの送信禁止(Adaptiva Referer Removerで代用可能)、JavaScript・Cookie・Refreshによる自動リロード・プラグイン・画像表示それぞれのタブごとの有効無効の設定、それらの情報をブックマークに保存する、といった機能か。

また後で改めて書くけど、タブブラウザ拡張いっこのためにOSのアップグレードすら半年以上(Firefox 2リリースの時から数えれば1年近く)できずにいたので、ついにここまで来たかぁ、と感無量です。

なお、TBE3に含まれている4つのアドオンはどれも一応最近のMinefieldで動作確認はしてるので、次のFirefoxメジャーアップデートの時には今回よりはすんなり移行できるんじゃないかなと思ってる。まあまだUIまわりが(特にタブが)色々変わる可能性はあるようなので安心はできないけど。

Tree Style Tab - ツリー型タブ - Oct 21, 2007

先日から作業してたものの成果がそれなりの形になったので、公開しました。

これだけでも当然使えるけど、僕としては情報化タブマルチプルタブハンドラの二つと組み合わせて使うのがお勧めだと思ってます。

実際に組み合わせて使ってる様子: (スクリーンショット)

元々、使い勝手のいいツリー表示アドオンが出てきたらそっち使う気でいたんだけど、TabKitが案外期待外れだった(←うわー言っちゃったー)ので一念発起して自分好みの物を作った。インデント幅を自動調整するようにしたとか、ドラッグ&ドロップでのタブの移動とツリー編集の挙動をIllustratorのレイヤツリー風にしたとか、TBEのタブツリーより完成度は地味に高くなってると思う。

突貫工事で作ったワリには案外ちゃんと動いてくれているなあ、というのが率直な感想。なめらかスクロールの実装やサブツリーの開閉まわりのコードをTBEからコピってきて使った箇所が少しだけあるけど、改めて今TBEのコードを見てみたら、タブのスクロール一つとってもとんでもなく面倒なことをしていたんだなあということに、我ながら改めて驚かされる。だって、普通にボックスの内容をスクロールさせるメソッドがなかったんですよ? バインディングを使って不可視のスクロールバーを取得して強引にスクロールの制御を行ってたとか根本的にバッドノウハウの塊すぎて、読み解くのも一苦労でした。あの頃から比べたらFirefoxの方でAPIを用意してくれてるところが増えてだいぶ楽になったもんです。

以下、検討事項。

  • ウィンドウをまたいだドラッグ&ドロップ……は、要望があれば考えよう。
  • ドラッグ中にタブバーの端をポイントしたら自動でスクロールするようにしたい。
  • 通常の横置きタブでも動くような設計になってはいるけど、十分テストしてなかったり、うっかり縦置きタブ用に決め打ちしちゃってるとことかあるかもだったりで、その機能は今は封印ということにしておく。ていうか自分じゃもうそんな機能使いそうにないし、やる気の度合いは非常に低い。
  • アイコンとかもうちょっとマシな物にしようよ。
  • 他の(僕が作った物以外の)タブ系アドオンとの組み合わせでちゃんと動くかどうかは知らない。要望が出てき次第対応していこう。
  • 複数リンクを選択してまとめて開く機能もこれに入れるべき?
  • Text Linkとの連携もしなきゃなぁ
  • iRiderのようにすべてのリンクを常にタブで開くモードを付ける?

タブのツリー表示がだいぶ実用的になってきた - Oct 19, 2007

一昨日から取りかかってる奴だけど、サブツリーの開閉を実装して、やっと実用的なレベルになってきた。ツリーの状態もタブセッションの情報の一部として記憶させているので、セッションをまたいでツリーを維持できるし、クラッシュした後の復帰でもちゃんとツリーが復元される、はず。

フォーカス制御やタブの親子関係の保持・取得についてはほとんど全部新規に書いたけど、ツリーの開閉関係はTBEの実装に基づいている。いやまあ、もちろんコードは新しく書き直してるんだけど、アルゴリズム(と言っていいのか?)の部分ね。

あともう一息だー

タブのツリー表示 - Oct 17, 2007

ようやく手を着けることにしました。TBEの機能を分割してFirefox 2向けに移植する作業の続きの中で一番めんどくさそうな、タブのツリー表示。Tab KitとかTab Treeとか、すでに新しくて素晴らしい物がどんどん出てきてるんだけど、まあ、マイペースで行くことにします。

(現状のスクリーンショット) サムネイルは情報化タブのもの。タブの縦置きは現在はVertigo任せ。公開版ではもちろん自前で縦置きするようにする予定だけど、今は「ツリー表示」のための部分に集中して開発するために敢えて放置してる。

親子関係の構築にあたっては、TBEでは「タブを開く」処理を乗っ取って引数でゴチャゴチャやってたんだけど、Tab Treeの発想が物凄くシンプルだったので、試しにそれベースで実装してみている。

TODO(優先順位が高い物から順に):

  1. targetwindow.open()で開かれたタブも親子関係の中に組み入れる→実装した
  2. タブを閉じた時の、次にフォーカスするタブの制御→実装した
  3. タブの親子関係をセッションをまたいで保持する(開き直したタブについても親子関係を自動的に復元する)→実装した(多分)
  4. ツリーの折り畳み→実装した
  5. 畳まれたツリーを閉じたら子孫のタブも全部閉じる→実装した
  6. 開かれたツリーで親のタブを閉じたら、子孫のタブのレベルを一つ繰り上げる→実装した
  7. Windowsエクスプローラのツリーのような自動開閉→実装した
  8. マルチプルタブハンドラとの連携(畳まれたツリーに対応するために特別な処理を書かないといけない)→実装した
  9. 畳まれたツリーについて、子孫に含んでいるタブの数を表示する→実装した
  10. ドラッグ&ドロップでの、ツリーの動的な変更→実装した
  11. タブの縦置きの自前提供(動的な幅変更も含む)→実装した
  12. タブを右に表示する機能→実装した
  13. インデント幅の設定機能→実装した:ユーザがいちいち人力で変更するなんてあほらしいので、インデント幅を自動調整するようにした(初期値は変更可能)
  14. 画面外にタブが開かれた場合の自動スクロール→実装した
  15. ウィンドウをまたいだタブのドラッグ&ドロップ

TBEに存在した、別のドメインのページを読み込んだ時にタブの親子関係を自動的に破棄するとかの細かい部分については、実装してみてはいたものの自分が使ってる限りでは全然役に立ったことがないので、サクッと省略の方向で。

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき