Home > Latest topics

Latest topics 近況報告

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

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

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

Page 7/243: « 3 4 5 6 7 8 9 10 11 »

そろそろFirefoxからChromeへの移行を本気で検討した方がいい気がしてきた - Feb 07, 2010

B.B.S/2628 "タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

Tree Style TabとJetpackを入れるとタブバーをスクロールするとタブの残像が残ったままになる。

[str]
1. Firefox3.6を新しいプロファイルにTree Style Tab-0.9.2010020502とJetpack-0.7をインストールし起動する
2.タブバーがスクロールするように多数のタブを開く
3. スクロールバーまたはホイールスクロールによりタブバーをスクロールする

[actual]
タブバーが正しくリペイントされずタブの残像が残る

[expected]
正しくリペイントされる。

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100206 Namoroka/3.6.2pre ID:20100206050755

B.B.S/2629 "Re: タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

widgetがどうとかのGecko 1.9.2での修正(異常に縦に長いページのレンダリングが壊れる問題に対する修正)の影響だと思われます。JetpackではSlidebarの実装のためにtabbrowserと同じ大きさのbrowser要素をopacity:0の状態でtabbrowserの下に重ねていますが、こいつのせいでレンダリングがおかしくなっています。

タブのcollapsed属性をいじってるTMPの多段タブならともかくTab Kitでも問題が起こらないのはなんでなんだ?と思ってスタイルシートを調べてみた所、scrollboxでスクロールさせてると駄目で、その中のbox.scrollbox-innerboxに対するoverflow:autoでスクロールさせてる場合はこの問題が起こらないようです。

しかしscrollboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェース経由でスクロール位置の操作が可能なのに対し、box.scrollbox-innerboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェースが取れません。結果、画面の外に新しいタブが開かれた時にその位置まで自動的にスクロールさせるという事ができなくなります。

「Jetpack 0.7と組み合わせても問題が起こらないが、画面外にタブが開かれるとフォーカスを見失う」
「画面外のタブにフォーカスが行くと自動的にそこまでスクロールしてくれるが、Jetpack 0.7とは同時に利用できない」
どっちがいいでしょうか。僕は後者です。(どうせ現状のJetpackはなくなるそうだし、その過程でなんとかしてもらいたいと思ってます)

掲示板の方では「現状のJetpackはRebootで置き換えられるそうだからそっちに期待」的な事を書いたけど、下手したらReboot後でもずっとこのままなのかもなーという風な悲観的な予想も捨てきれずにいます。

norahさん曰く、同じ問題がサードパーティ製のテーマとJetpackとの組み合わせにおいても発生するそうです。既存のアドオン、既存のテーマについては「冷遇」して、JetpackとPersonasへの移行を促したいという事をMozillaの偉い人が言ってたらしいけど、実装レベルで着々と実力行使が進んでる感がありますね。

対するGoogle Chromeでは、タブの縦置きが試験的に実装され始めてるそうです。こんな事を書いたばかりですが、そろそろ本気でGoogle Chromeへのエクソダスを図った方がいいような気がなんとなくしてきました。

今までできていたことが少しずつできなくなっていく、締め付けが強まっていくストレスというのは、いざ自分が締め付けられる立場になるととても辛いものですね。それならいっそ、最初から制限がきつくても将来性のある新天地に移ってしまおう、と考えても変じゃないよなあと思いました。Mozilla SuiteからFirefoxに移行した時以来、レンダリングエンジンの違いで言えばDonutからMozillaに移行した時以来なので、今更それがほんとに可能なのかという不安はありますが。

ツリー型タブのGoogle Chrome版は作らないの?(Tree Style Tab for Google Chrome) - Feb 05, 2010

Q

Any plans to add Tree Style Tab to Google Chrome or Chromium?

ツリー型タブをGoogle ChromeもしくはChromiumに移植する計画は無いの?

A

Now I have no plan to export Tree Style Tab to Chrome. The fact "Tree of tabs are permanently shown, without any operation" is the best benefit of Tree Style Tab for me. Currently there seems to be no API to do it. I don't want to use such a feature if clicking on a toolbar button (or any other operation) is required to show the view.

Moreover, it is the main reason of my development that I want to improve my PC environment. Because I'm not planning to switch to Chrome, I will not develop Chrome extensions.

By the way, there are some similar extensions VerticalTabs, Tab Menu, and Tree Style Tabs (Beta) (Note: it has same name but it is NOT my product!). They possibly help you.

Updated at 2012-11-22: More extensions, Sidewise Tree Style Tabs and Tabs Outliner are available now. They are good alternative of Tree Style Tab on Google Chrome.

今の所、私自身がツリー型タブをChromeに移植する予定はありません。私は、「ツリー型タブ」の便利な所は「タブの一覧(ツリー)が常時表示されている」点だと思っています。現状のChromeの拡張機能向けのAPIでは、そのような拡張機能は残念ながら作ることができないようです。ボタンをクリックしないとツリーが表示されないような機能は、自分は使いたくないです。

また、私自身の開発のモチベーションは主に「自分が日常的に使う環境を使いやすくしたい」という所に支えられています。私は今の所Chromeを常用するつもりが無いため、Chrome用拡張機能を開発するモチベーションがありません。

なお、似たような拡張機能でVerticalTabsTab MenuTree Style Tabs (Beta)(注:同じ名前ですが私が開発した物ではありません!)というものがあります。まずはこれらを試してみてください。

2012-11-22追記:その後、Sidewise Tree Style TabsおよびTabs Outlinerという拡張機能が公開されています。これらを使うと、ツリー型タブにより近いユーザー体験をGoogle Chrome上で得られます。

ツリー型タブでタブバーの「新しいタブ」ボタンを隠せなくなった(How to hide "New Tab" button in the tab bar?) - Feb 05, 2010

Q

I just updated the Tree Style Tab addon and the new tab button that used to be hidden is now visible. Is there a way to hide it? I always use Ctrl-T, so it just wastes space.

ツリー型タブを更新したら、今まで隠れていた「新しいタブ」ボタンが表示されるようになってしまいました。これを隠す方法はありませんか? 私はCtrl-Tをいつも使っているので、このボタンは不要です。

A

Sorry, I removed the option because it is not a feature related to "tree". Instead, you'll hide the button by customizing your userChrome.css like:

.tabs-newtab-button {
    display:none !important;
}
/* hide the "shadow" */
tabbrowser
  .tabbrowser-strip
  .tabbrowser-tab
  .tabs-container
  .scrollbox-innerbox {
    background-image: none !important;
}

Note: These examples work on Tree Style Tab 0.8.2009100101 or later.

すみません。「ツリー」と関係ないものだったので、その機能は削除してしまいました。代わりにuserChrome.cssに上記のようなスタイル指定を書き加える事で、ボタンを非表示にできます。

縦置きタブバーの下にサイドバーを統合するUnified Sidebarをリリースしたよ - Feb 05, 2010

とりあえずMozilla Add-onsに置いた

ツリー型タブに対して表題のような要望が寄せられることが何度かある。ツリーと関係ないからツリー型タブにそういう機能を入れる気はないんだけど、まあそういうニーズはあるんだろうなというのは理解できる。なので以前にuserChrome.cssでそれっぽくする方法を考えてみたりもした。その時の結論としては「ちゃんとアドオンにしないと駄目だね」という感じだったんだけど、結局誰もアドオン化してくれてなかったようだったので、仕方がないから自分で作った。

このアドオン自体はタブを縦置き表示する機能は持ってません。単にサイドバーの表示位置を変えるだけです。タブを縦置きするにはuserChrome.cssで頑張るか以下のアドオンを使って下さい。

他にもタブを縦置きするアドオンがあれば、なるべく連携するようにはしたいので、このエントリにコメント付けるなどして教えて下さい。

Firefox上のあらゆる操作を一次元で記録してアンドゥ・リドゥ可能にするライブラリ(実験段階) - Jan 04, 2010

ツリー型タブのAPIでこんなのが欲しいというのがあったら言っておくれと書いたところ、Alice0775さんからタブバーのドラッグ操作とかツリーのドラッグ操作とかをアンドゥする機能が欲しい(大意)という要望をいただいた。

そういえばこの前のMozilla勉強会の後の懇親会で、新しいタブが開かれたり新しいウィンドウが開かれたりした時に「戻る」ボタンで元のタブや元のウィンドウに戻れないことについて、あらゆる操作がアンドゥ可能になってないといけないんじゃないの?とかそんな感じの話が出ていたと思う。なので実験的にそういう物を作り始めてみた自動テスト)。

var current = TreeStyleTabService.currentTabbarPosition;
window['piro.sakura.ne.jp'].operationHistory.doUndoableTask(
  // やり直し可能にしたい処理
  function() {
    TreeStyleTabService.currentTabbarPosition = newPosition;
  },

  // 履歴の名前(省略可)
  'TabbarDNDOperations',

  // ウィンドウごとの履歴の場合の対象ウィンドウ(省略可)
  window,

  // 履歴の項目
  {
    // 項目名
    label  : 'タブバーの位置変更',
    // アンドゥの時に実行する内容
    onUndo : function() {
      TreeStyleTabService.currentTabbarPosition = current;
    },
    // リドゥの時に実行する内容(省略可)
    // →省略時は上記の「やり直し可能にしたい処理」が自動的に
    //   onRedoとして登録される
    onRedo : function() {
      TreeStyleTabService.currentTabbarPosition = newPosition;
    }
  }
);

という感じでアンドゥ・リドゥ時の動作を登録して、window['piro.sakura.ne.jp'].operationHistory.undo('TabbarDNDOperations', window)とかwindow['piro.sakura.ne.jp'].operationHistory.redo('TabbarDNDOperations', window)とか書くとヨロシク処理してくれる……という風な感じ。「あらゆる操作を一次元で記録して」とタイトルに書いてるけど、自動的に記録するんじゃなくてアドオン作者が手作業で記録する前提で、「履歴の記録」「履歴の呼び出し」の所を管理する手間を軽減するだけのライブラリなんで、そこの所はお間違えなきよう。

関数をそのまま登録するというのが乱暴と言えば乱暴なんだけど、柔軟性を高くしようと思ったらこうするのが手っ取り早いかなーって思いまして。一応ウィンドウごとの履歴とグローバルな履歴の両方を持てるようにしてみてる。イメージ的には、Adobe製品のヒストリ機能のような物を目指してる。

で、枠組みは用意したんだけど、タブバーの位置の移動みたいな単純な機能はいいとして、ツリーの移動みたいなややこしい物をどうやってアンドゥ・リドゥさせるかで暗礁に乗り上げてる。

  • マルチプルタブハンドラとの連携も考慮する必要がある。
  • ツリーの移動だけじゃなく複製も考慮しないといけない。
    • 複製のアンドゥは複製されたタブのクローズでいいけど、リドゥは? もう一回複製させる?
  • 移動・複製元のタブの一部が閉じられていた場合を考え始めると破綻する。
    • ツリーの移動だけを記録すると、ツリーを移動した→移動先のツリーのタブを1つ閉じた という操作の後でアンドゥした時に、移動されたツリーを元に戻せない(元のウィンドウに戻すべきタブが見つからなくなる)。
    • となると、タブを閉じる・タブを開く・(ツリーに関係なく)タブを移動する、といったあらゆる動作を記録しないといけない。

なんとなく、ツリー型タブからは分離して「タブバー上のあらゆる操作をアンドゥ可能にするアドオン」を新しく作った方がいいような気がしてきた。で、ツリー型タブが入ってる時はそいつのアンドゥ履歴の中に「タブバーの位置変更」の項目が混ざってくる、みたいな連携の仕方。

ツリー型タブとTabberwockyを同時に入れられるようにしたよ - Dec 25, 2009

Tree Style Tab 0.8.2009122501Tabberwocky用のコードを入れました。とりあえず、選択範囲のリンクをタブで開く機能と、新しいタブを現在のタブのすぐ隣に開く機能については、ちゃんと動くことを確認してます。他にうまく動かない機能があったら言って下さい。Tab Mix Plusに比べたら全然コードの量も少ないんで、たぶん対応できると思う。

Tab Mix Plusと組み合わせた時の問題もどうにかしようと思ったんだけど、見てみたらTMPの中にTST用のコードが入ってたので、さっくり諦めた。お互いがお互いに手を出すともはや収拾が付かなくなるから。なのでちょうどいい機会だと思って、TMPのフォーラムに「いいかげんこの状況なんとかしようよ」的な提案を書き込んでみた。そのついでに、ソースコード中で「PUBLIC API」と書いておきながら説明を書き忘れてたAPIをドキュメントに追加した

他のアドオンと連携を取りやすくするためのAPIを加えるのはやぶさかじゃないので、要望があれば是非言ってください。最近の例では、TreeStyleTabService.currentTabbarPositionTreeStyleTabService.treeViewEnabledはメールで「こういう事をしたいんだけどどうすればいいのさ」と問い合わせを受けたので追加したAPIです。

画面の描画内容を一時的にロックしておいて、裏であれこれして最後にまとめて描画させる方法の再考 - Dec 24, 2009

画面の描画を一時停止する方法を先日書いたけど、案の定というかやっぱりというか、重大な弊害があることが分かった。また、その弊害にぶち当たらない安全なやり方も見つけることができた。

安全に画面の描画を一時停止・再開する方法は、以下の通り。

var baseWindow = window.top
                   .QueryInterface(Ci.nsIInterfaceRequestor)
                   .getInterface(Ci.nsIWebNavigation)
                   .QueryInterface(Ci.nsIDocShell)
                   .QueryInterface(Ci.nsIBaseWindow);
baseWindow.setPosition(window.innerWidth, window.innerHeight); // これで画面の描画が止まる

gBrowser.addTab(); // これによって起こる変化は画面上に現れない
gBrowser.addTab(); // この変化も画面上に現れない
gBrowser.addTab(); // 同上

baseWindow.setPosition(0, 0); // ここでやっと描画が再開される

以下、前のエントリに書いたやり方にどういう弊害があるのか、および、このエントリで紹介するやり方の方がどのくらい安全なのかについて詳しく説明する。

続きを表示する ...

ツリー型タブ0.8.2009122103 - Dec 21, 2009

ツリー型タブはバグをつぶし始めたらきりがなくなってきたので、適当なところで打ち切ってリリースしました。バグ報告への返信で「I'll update as soon.」とか書いちゃったからというのもある。

画面の描画内容をロックするアレについては、結局ライブラリ化しましたwindow['piro.sakura.ne.jp'].stopRendering.stop()で描画停止、window['piro.sakura.ne.jp'].stopRendering.start()で再開します。複数の機能で停止/再開をネストしても大丈夫なように、呼び出し回数をカウントするようにしてあります。start()し忘れると変なことになるので注意して下さい。

他にもいくつかAPIを追加したので、自作アドオンと連携して動作させてみたい人は参考にして下さい。

画面の描画内容を一時的にロックしておいて、裏であれこれして最後にまとめて描画させる方法 - Dec 18, 2009

ツリー型タブとJetpackが同時にインストールされているとコンテンツ表示領域に何も表示されなくなってしまう、という問題の原因がやっと分かった。そこからさらに調査をして、表題のような「画面の再描画を任意に停止・再開させる」方法が見つかった。

先にやり方だけ書いとくと、こうするとできる。

var rootContentViewer = window.top
                          .QueryInterface(Ci.nsIInterfaceRequestor)
                          .getInterface(Ci.nsIWebNavigation)
                          .QueryInterface(Ci.nsIDocShell)
                          .contentViewer;
rootContentViewer.hide(); // これで画面の描画が止まる

gBrowser.addTab(); // これによって起こる変化は画面上に現れない
gBrowser.addTab(); // この変化も画面上に現れない
gBrowser.addTab(); // 同上

rootContentViewer.show(); // ここでやっと描画が再開される

24日追記。この方法には重大な弊害があることが分かりました。使用を検討している人はより安全な方法を使うようにして下さい。

以下は、これに辿り着いた経緯のお話。

続きを表示する ...

Page 7/243: « 3 4 5 6 7 8 9 10 11 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき