Home > Latest topics

Latest topics 近況報告

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

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

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

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 10/239: « 6 7 8 9 10 11 12 13 14 »

ツリー型タブ - Oct 15, 2008

ツリー型タブ 0.7.2008101501。前の版から4ヶ月も経ってた。使ってて見つけたバグはちまちま直してたんだけど他のユーザの人から英語で寄せられるバグ報告を放置放置でほったらかしてる間にまたずいぶん溜まってしまったのでちょっと頑張って処理してみた。FireGesturesの仕様変更への追従なんてもう何ヶ月も前の変更だから、もう意味が無くなってるかもしれないけど……まあ誰かに言われたら直そう(ぉぃ)。

Menu Editでタブのコンテキストメニューの項目が無限増殖する問題は、多分、分割ブラウザとの組み合わせを見越して各tabbrowser要素ごとにポップアップメニューの項目に一意なid文字列を生成するようにしていたせいだと思う。<tabbrowser id="content"/>なやつだけ特別に固定のidにするようにして、手元で試した限りでは無限増殖の問題は起こってない。マルチプルタブハンドラでも同じ問題が起こってるはずなので(報告すでに受けてたかも。あまりに多すぎて埋もれてしまってる可能性大。)、これは次のリリースで同じ修正を入れます。

Tab Mix Plusとの組み合わせで色々問題が起こってるという報告を受けてるけど、設定項目が多すぎてどの組み合わせで問題が起こるのか分からないのでお手上げです。とりあえず簡単に手元で試して再現しなかった物は放置。

Firefox 3での変更点(重箱の隅を突く的な) - May 26, 2008

アナウンスに含まれてるかどうか知らないけどものっそ細かい所での変更点で僕が詰まった所。

  • Windowsにおいて、ドラッグ中でもタイマーが機能するようになった
  • nsIDocShellTreeItemのchildOffsetプロパティがなくなった

まず一つめ。Firefox 2まででは、何かオブジェクトをドラッグしてる間はsetTimeoutやsetIntervalで設定したタイマーが発火しないという問題があった(ドラッグ&ドロップ中のタイマーを擬似的に再現する)。これが、いつの時点からかFirefox 3ではWindowsでも普通にタイマーが動作するようになってた。セカンドサーチツリー型タブで「ドラッグ中に検索バー(タブ)の上でしばらく待つと〜」系の動作がうまく機能しなくなっていたのは、これが原因。Firefox 3以降ではWindows環境でも普通にタイマーを使うようにコードを書き換えたらうまく動くようになった。

二つめ。 個々のフレームに対応するnsIDocShellのオブジェクトを取得するなどで触れたnsIDocShellTreeItemインターフェースについて、Firefox 3ではchildOffsetプロパティがなくなってしまった。XUL/MigemoでFirefox 3においてフレームを跨いだ検索ができなくなっていたのはこれが原因(今フォーカスしてるフレームの次のフレーム、を取得するためにこのプロパティを使っていた)。かっこ悪いけど、親フレームの子フレームリストを取ってきてループ回してchildOffsetに相当する値を算出するようにしたらうまく動くようになった。

なんで今更になってこんな所(後者)をいじったんだか……

タブバーを自動で隠す時の透過の様子のデモ - Mar 11, 2008

ツリー型タブでタブバーを自動で隠す設定の時に、うそっこ透過タブバーで下の物が見えるようにした、と書いたけど、その様子のデモを作ってみた。

こうして見てみるとスタック型タブとあんま変わらんように見えるな……

そういや昨日これのためのコード書いてたら、Minefieldでタブバーの幅が300ピクセル以下にならなくて、おっかしーなーと思って色々詳しく調べてみたら、HTML Canvasの幅を0にしようとすると問答無用で300ピクセル幅(canvasの初期状態の幅)になってしまうようだった。さらに検証してみたらFirefox 2ではその逆に高さを0にできないという現象も……Bugzillaを検索してみてもクエリが「canvas width」だとやたらたくさん引っかかって同じバグがすでにあるかどうか分からなかったので、とりあえずバグを立ててみた。ガイシュツだったらすんません。ちなみに幅も高さも、最小値は1ピクセルまでだったらちゃんと指定通りに動くようです。というバッドノウハウ。

追記。しばらく使ってみたら、タブの下の何もないスペースを、タブバーがあることを忘れてうっかりクリックしてしまうということが頻発したので、タブバー部分はそうと分かるように色を変えるようにした。

ウィンドウ全体を覆い隠してゴニョゴニョするためのライブラリを作った - Mar 10, 2008

ツリー型タブでタブバーの表示・非表示を切り替える時の画面のちらつきがUZEEEEEEEEEE!!というのは前々から把握してたんだけど、一時的に画面描画を止めるとかそういうのはJavaScriptのレイヤからは手が出せないっぽいので放置してた。AutoHideではC++あたりでXPCOMコンポーネントを作ってどうにかしてるようだけど、そんなん僕には作れないし。

でもよく考えたらHTML Canvas使って解決できるんじゃね? と思って、そういう物を作ってライブラリ化してみたfullScreenCanvas.show()を呼ぶと、今のウィンドウの表示内容のスクリーンショットを貼り付けたような状態のCanvasがウィンドウ内の要素の最前面に表示されます。画面がチラつくような処理をその下でやって、終わったらfullScreenCanvas.hide()でCanvasを消す、という風にすると、ユーザにイヤンな思いをさせないでいろんな事ができるかも知れない。ブラウズ領域のスクロールバーの部分が描画されないのはどうにもならなかった。

以下、工夫した所。

  • Minefield 3.0b5preではposition:fixedにしてもCanvasがブラウズ領域の描画内用の下に潜り込んでしまう。フレーム(iframe, browser, tabbrowser)があるとそっちの方が上に描画されてしまうようだ。というわけでGecko 1.9の時だけbrowser要素を動的に生成してその中にcanvasを置くようにした。
  • Firefox 2でも、position:fixedを指定したcanvasがブラウズ領域の下に潜り込んでしまう。これは毎回positionプロパティの値を指定し直してやる事でうまく動くようになった。
  • drawWindowは、フレームを含むwindowを指定した場合はサブフレームの中身まで描画するけど、Chrome Windowを指定した場合はbrowser要素やtabbrowser要素で形成されるサブフレームの中身が描画されない。しょうがないので、browser要素やtabbrowser要素を全部収集してループで一つずつ描画するようにした。

XULとCSSのポジショニングの組み合わせは、Gecko 1.9でもバッドノウハウの塊ですね。

Firefox 3のタブにFirefox 2と同じプレースホルダーを復元するライブラリと併せて、MITライセンスでの公開とします。

追記。canvasついでに(意味不明)、タブバーの後ろにcanvasを置いてうそっこ透過タブバーを実現してみた(描画内容が微妙にズレることがあるのは勘弁してください)。これで、ページの閲覧を邪魔されずにタブバーを使えるようになるだろうか?

ツリー型タブの最近 - Feb 28, 2008

ここ最近のツリー型タブの状況まとめ。

先週末くらいから現実逃避度合いが加速して、それがそのまま頻繁なバージョンアップに繋がっています。この1週間くらいでやったことのうち大きなトピックは以下のような感じか。

  • 公開申請が通って、晴れてサンドボックスから出た。
  • Firefox 3 Beta3(正確にはb4pre)対応。
  • タブバーの固定、表示位置変更をコンテキストメニューから可能にした。
  • マルチプルタブハンドラでの複数タブドラッグに対応。
  • HighlanderPermaTabsColorfulTabsSuper DragAndGoDrag de Goとの競合の解消・連携を強化。

他、細々とした改善が多数。だいたいAMOの配布ページディスカッションに寄せられてた障害報告や要望への対応が多い。

以前TBEをやってた頃は、あまりに規模がでかかったこともあって、とてもじゃないけど他の拡張機能のために配慮するなんて事はできなかった。その点ツリー型タブとかの最近作った物は、なるべく機能を絞り込むように・見通しがよくなるように気をつけている(つもり)ので、あの頃よりもずっと楽にコードを書けてると思う。具体的に名前が挙がったアドオンについて、わりと片っ端から対応用のコードを書いていけてるのも、そういう事情があってこそだ。

しかしいくらサンドボックスから出られたからとはいえやたらたくさんコメントが付いて、正直追いかけるのだけで大変だ。何でだ?と思ってたら、数日前にlifehackerで紹介されてた。コメント欄を見てみると、おおむね好評なようで嬉しい。Firefoxのユーザ全体のうちこの拡張機能を使ってくれてる人の割合は物凄く小さいものだとは思うけど、英語圏はなにぶん人の数が桁違いに多い。英語でリリースしておくと日本語だけでリリースするより多くの人に誉めて貰える&喜んで貰えるので、僕のような構ってちゃんで誉めてもらえないとロクに動けない人間にとっては、その点では都合がいいと言えるかもしれない。

マルチプルタブハンドラで複数タブをまとめてドラッグ&ドロップできるようにしたよ - Feb 24, 2008

表題の通り。Multiple Tab Handlerではタブを選択して操作する機能があるけど、選択後のタブをドラッグ&ドロップしたら全部一緒に移動するようにしてみた。

というのはわりとすぐにできたんだけど、ツリー型タブとの組み合わせが少し大変だった。ツリー型タブがある状態のタブの移動は、単にタブの位置を変えるだけじゃなく、ツリー構造の変更も伴うから。故にツリー型タブではタブのドロップ時の処理をほとんど丸ごと置き換えるようにしていて、そっちの方でMultiple Tab HandlerのAPIを使って対応する(つまりMultiple Tab Handlerはツリー型タブがあるときは、タブのドロップ時は特に何もしない)ようにした。

あと、Firefox 3ではCtrl-ドラッグでタブを複製できるようになってるんだけど、ツリー型タブをこれに対応させるのにも手間取った。というか、今まで適当な処理でそれなりに動いてた部分について潜在していたバグが一気に表面化したという感じ。丸1日くらい使って地道に直した。

ツリー化された複数タブの選択→ドラッグ&ドロップの挙動については、例によってAdobe Illustratorのレイヤ/オブジェクトツリーの挙動を参考にしてる。

以下は未実装の項目。

  • Firefox 3ではウィンドウをまたいでタブをドラッグすると「タブの移動」扱いになるけど、ツリー型タブはまだこれに対応していない。→Tree Style Tab 0.5.2008022402で対応
  • Ctrl-ドラッグでのタブの複製、ウィンドウをまたいだドラッグ&ドロップによるタブの移動について、Multiple Tab Handlerはまだ対応していない(ツリー型タブの方にかまけててすっかり忘れてた)。→Multiple Tab Handler 0.2.2008022402で対応
  • タブのドロップ先がタブバー以外の場合はタブで開いてるページのURIが渡されるんだけど、これも選択されたタブ全部のURIを渡すようにした方がいい? 受け入れ側が複数URIのドロップを想定していない場合は動作がおかしくなる気がする。ああでもHTMLとかプレーンテキストとか、他のアプリケーションやテキスト入力欄に対してのみ渡されるflavourなら問題ないか?

APIを作る時はどんな使われ方をするかちゃんと考えてから作ろうという話 - Nov 30, 2007

ツリー型タブでずっと前から発生条件が分からなくて困ってた「一つもタブが選択されていない状態」になってしまうバグの原因がやっと分かったので、速攻で修正した。

この問題は、以下の条件がすべて揃った時に発生していた。

  • タブバーの末尾に、ツリー状になったタブがある
  • そのツリーが折り畳まれた状態で、ツリーの最上位の親のタブが選択されている
  • そのタブを閉じる操作を行う

この時、内部的にどういう処理が行われていたかというと、以下のような感じだ。

  1. removeTabメソッドが呼ばれる
  2. removeTabメソッドにてTabCloseイベントが発生
  3. TreeStyleTabBrowserのインスタンスがTabCloseイベントを捕捉
  4. 1で閉じられようとしているタブがツリーの親で且つ子孫タブが折り畳まれている場合、TreeStyleTabBrowserが子孫タブを先に閉じる
  5. TreeStyleTabBrowserのTabCloseイベントに対する処理が完了
  6. removeTabメソッドの残りの部分に制御が戻る
  7. 閉じようとしているタブが、選択されたタブだった場合、次に選択するべきタブを決定し、そのタブを選択する
  8. removeTabメソッドの処理が完了

この「TabCloseイベント」というのがFirefox 2以降で使えるAPIなんだけれども、問題は7のステップで起こっていた。7のステップで「次に選択するべきタブ」を決定するためのキーとして「現在開いているタブの総数」を使っているのだけれども、その値は1のステップの間に取得しているため、1から7までの間のどこかでタブの数が増減した場合、タブの選択状態が狂ってしまうのである。7のステップで「現在のタブまたはそれよりあとのタブ」が選択される場合、ここでは4のステップでタブの数が減少しているため、「次に選択するタブの番号」が「すでに削除されたタブ」のインデックスを指し示すことになり、selectedTabの値がundefinedとなりNull Pointer Errorが発生してしまう。……というのが事の真相だった。

ツリー型タブの側でselectedTabのセッタを上書きし、もし存在しないタブが選択されそうになった時は強制的に最後のタブを選択するようにしたところ、「一つもタブが選択されていない状態」は発生しなくなった。以下はそのためのコード。

// var b = gBrowser

var getter = b.__lookupGetter__('selectedTab');
var setter = b.__lookupSetter__('selectedTab');
eval('setter = '+setter.toSource().replace(
    '{',
    '{ if (!val) val = this.mTabContainer.lastChild;'
));
b.__defineGetter__('selectedTab', getter);
b.__defineSetter__('selectedTab', setter);

この部分ではなく、removeTabメソッドを上書きするという手もあるんだけど、ここはいろんなアドオンが上書きしたがるためコンフリクトの原因になると思ったので、「標準的な動作と変わってしまう」ことは仕方がないと割り切って、ほとんど誰も触らないであろうselectedTabの方を上書きするようにした。ちなみに、ゲッタとセッタ両方を定義し直しているのは、片方だけを再定義するともう片方が未定義になってしまうから。

表題の件に流れを戻すと、「タブを閉じる」という操作をイベントとして捕捉できるようにしたのなら、そのイベントをトリガーにして他のタブを連動して操作するという機能も当然登場してくるわけで、そういうことを考慮せずに「はいはいイベント発行すりゃいいんだろdispatchEvent っと!」と適当に設計してしまうとこういうトラブルが起こるので、APIを作る時にはもうちょっと慎重になった方がいいよね、という教訓を得たという話なのでした。

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

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

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

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

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

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

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

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

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

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

ツリー型タブとTab Mix Plus - Nov 13, 2007

需要がどれだけあるか分からんけど、ツリー型タブをTab Mix Plusと同時に使えるようにしてみた。といっても左右にタブバーを表示した場合限定で、それ以外の場合については全然まったく動作確認を行っていないので要注意。とりあえず多段タブの設定になってる時はそれを自動的にキャンセルするようにはしてあるけど、TMPの設定次第ではグッチャグチャになる可能性もある。

TMPによって改変された後のDOMツリーは旧TBEを思わせる混沌とした有り様で、解析するのにえらく骨が折れた……

タブブラウザ拡張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まわりが(特にタブが)色々変わる可能性はあるようなので安心はできないけど。

Page 10/239: « 6 7 8 9 10 11 12 13 14 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード