たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
174 :名無しさん@お腹いっぱい。 :2009/04/05(日) 00:30:55 ID:Jg57WUq90 Shiretokoでjit;trueでも堕ちなくなってる? http://piro.sakura.ne.jp/ 215 :名無しさん@お腹いっぱい。 :2009/04/06(月) 04:39:05 ID:xzi0BQ5U0 >>174 亀で済まんが、piro氏のとこは3.1b3では、jit.chromeを有効にするとクラッシュする。 3.1b2は大丈夫。3.1b3で投入されたjit処理のバグが原因。 3.6a1preや3.1b4preの直近ビルドでは、バグ修正されてクラッシュしない。 なので3.5b4では大丈夫になる。 221 :名無しさん@お腹いっぱい。 :2009/04/06(月) 20:43:26 ID:lkNWsC2v0 Fx をクラッシュさせる Piro のサイトが問題。 Piro は即座に Web ページを改善するべき。 222 :名無しさん@お腹いっぱい。 :2009/04/06(月) 21:00:11 ID:PQ+QMUPz0 Minefieldバグ検証用として残しておくべき
ストレステストですね、わかります。
頭で分かったつもりになってても本当のところは理解できてないことって、多いもので……自分が当事者になってみないと分からなかった。今もちゃんと分かってるか怪しいくらいだ。賢者は歴史に学び愚者は経験に学ぶと言うけれども、僕はまさに愚者だなあ。愚者未満かも?
何でも話せる関係、とか、何でも受け入れられる関係、とかって、一歩間違うとズブズブの共依存に陥っちゃうアレですよね。多分その一種。あまりに典型的すぎるのに……自分のこととなるとなんで気付かないんだろ。いや、気付きたくなかったんだな。必死で目を逸らしていただけだ。
自分の「至らないところ」までも相手が受け入れてしまうと、自分でそれが「至らないところ」だって気付けなくなる。根拠レスな自信が増大していく。まぁ、自信喪失状態からのリハビリにはなったのかもだけど。でも、甘やかされると図に乗るタイプの人間は……度が過ぎても自分で気付くことができないんだな。人に言われても分からない。鏡のように自分の有り様を見せつけられて、なんとか分かるのかもしれない。
ありのままを一人で全部受け入れられることなんて、そうそうないんだろうな。本来なら多分どっかで破綻するんだと思う。破綻してなかったら何かがおかしい。会社だったら、赤字垂れ流してどうやって成立してるの?みたいな話だ。その裏には何かカラクリがあるか、そもそも最初から商売なんかしてなかったのか……
最初は自分が被害者みたいな気分にもなってしまったけど、違う、共犯だ。共依存だもん。むしろ自分が主犯だろ、自分の人生的に考えて。
それに、サインは出してくれてたんだな。決められたのは間違いなくそのおかげだ。なのに今まで僕は自分から、それを無視してた。まじめに取り合おうとしてなかった。サインの意味を懇切丁寧に教えてもらってやっと、「ああそういうことなのか」って分かったわけで。どこまで僕は人任せなんだよと。救いようがないなホントに!
だからなあ。恨めないわ。っていうか自分だけおいしいとこいただいてちゃっかりエクソダスしちゃって、むしろ恨まれておかしくないよなあ。
ありがとうね。本当に。さようなら。
うおおおおおお!
キモイ!! これはキモイ!!! この主人公のキモさは僕のキモさだ!!!!!
この手の男に心底ウンザリしてるんであろう女の人が書いたレビューを先に読んだので、そういう目でしか見れませんでした。
この作品読んで「久保せんせえは女性なのにモテない男性の気持ちがよくわかっててすごいな!」と喜ぶ男子が多そうですけど、久保せんせえ以外も、女性はみんな、お前らのふがいなさをよっく分かって日々いらいらしてんだよ、という事実にまで気付いたらいいのに、と思います。
ああもうほんとに。他人の目から見たらお前はこう見えてんだよ、こんなんだから恋愛関係やめて友達になりたいって言われるんだよ、ってのがよく分かった。嫌な意味で。
これ系の漫画では最近だとルサンチマンとかボーイズ・オン・ザ・ランが有名だと思うけど、花沢健吾の描く物語の主人公は、容姿的には不細工だったりパッとしなかったりドジだったり弱虫だったりする割に、どこか一生懸命である意味かっこよかったりする。それに対してモテキの主人公は、真逆の描かれ方だ。容姿はそんなに悪い風ではなさそうな描かれ方なのに、性格ブスっていうかなんていうか、内面のかっこ悪さがハンパ無い。「見た目はかっこよくないけど中身はかっこいいんだぜ!」というモテナイ男の自己陶酔を真っ向から否定する嫌なリアルさ、「見た目もだけどそれ以前に中身が駄目じゃん」という現実が、ここにはある。
しかしなんでここまで僕はこの主人公を否定してしまうのだろう。言い換えると、彼一人を悪者にして、他の登場キャラの醜さに目を向けないのだろう。多分だけど今も僕は、女性というものを強者と認識しているんだと思う。一般的な意味で強い強者か、「弱者」という免罪符を持っているという意味での強者か、どっちにしても。争っても周囲から自分(男)の側が一方的に責められる、だからアンタッチャブルにならざるを得ない、そんな感じの。
trunkでとうとうgetBoxObjectForがエラーを吐くようになってしまった - alice0775のファイル置き場 - Yahoo!ジオシティーズ
これを見て焦って今頃になってやっと調べた。
パッチによると、nsIDOMNSDocumentからgetBoxObjectFor()
が消えて、nsIXULDocument専用のメソッドになった。ということなので、HTMLDocumentでgetBoxObjectFor()
を使っているコードは全滅だ。何とかして代わりの方法を見つけないといけない。
document.getBoxObjectFor(element)
で取れるのはnsIBoxObject、element.getBoundingClientRect()
で取れるのはnsIDOMClientRectで、インターフェースが違う。
取りたい値 | nsIBoxObject | nsIDOMClientRect |
---|---|---|
ボックスの幅 | box.width | rect.right-rect.leftまたはrect.width |
ボックスの高さ | box.height | rect.bottom-rect.topまたはrect.height |
ボックスの左上の点のX座標(ドキュメントの原点基準) | box.x+左ボーダー幅 | rect.left+window.scrollX |
ボックスの左上の点のY座標(ドキュメントの原点基準) | box.y+上ボーダー幅 | rect.top+window.scrollY |
ボックスの右下の点のX座標(ドキュメントの原点基準) | box.x-左ボーダー幅+box.width | rect.right+window.scrollX |
ボックスの右下の点のY座標(ドキュメントの原点基準) | box.y-上ボーダー幅+box.height | rect.bottom+window.scrollY |
ボックスの左上の点のX座標(ビューポートの原点基準) | box.x+左ボーダー幅-window.scrollX | rect.left |
ボックスの左上の点のY座標(ビューポートの原点基準) | box.y+上ボーダー幅-window.scrollY | rect.top |
ボックスの右下の点のX座標(ビューポートの原点基準) | box.x-左ボーダー幅+box.width-window.scrollX | rect.top |
ボックスの右下の点のY座標(ビューポートの原点基準) | box.y-上ボーダー幅+box.height-window.scrollY | rect.bottom |
nsIDOMClientRectのwidth
とheight
はどうもGecko 1.9.1以降でしか使えないっぽい。
例えば今使ってる環境のdocument.getElementById('reload-button')
の場合はこんな感じ。
この時の値は以下の通り。
nsIBoxObject | nsIDOMClientRect |
---|---|
box.width==36 | rect.width==36 |
box.height==36 | rect.height==36 |
box.x==83 | rect.left==82 |
box.y==23 | rect.top==22 |
rect.right==118 | |
rect.bottom==58 |
x
とleft
、y
とtop
の間にずれがあるのは、nsIBoxObjectのx
とy
がいわゆるborder-box(border + padding + contentのボックス)ではなくpadding-box(padding + contentのボックス)基準であるからということらしい。nsIBoxObjectからborder辺の座標を取るには、getComputedStyle()
でborderの幅を取って計算してやらないといけない。nsIBoxObjectもnsIDOMClientRectも、これら以外のプロパティはborder-box基準のようだ。
で、上の表には書いてないけど、nsIBoxObjectにはscreenX
とscreenY
というプロパティがあって、こちらで取れる画面上の座標もborder-box基準。そして、nsIDOMClientRectにはこれらプロパティが無いので、画面上の座標を取ることができない。
大まかに言って、nsIBoxObjectのx
はnsIDOMClientRectのleft
、nsIBoxObjectのy
はnsIDOMClientRectのtop
に読み替えて差し支えない。となると、残る問題は、screenX
とscreenY
に相当する値をどう取るかだ。
で、試行錯誤の結果、以下のようなコードができあがった。
function getBoxObjectFor(aNode)
{
// getBoxObjectFor() がある時はそれを使う。
if ('getBoxObjectFor' in aNode.ownerDocument)
return aNode.ownerDocument.getBoxObjectFor(aNode);
var box = {
x : 0,
y : 0,
width : 0,
height : 0,
screenX : 0,
screenY : 0
};
try {
var rect = aNode.getBoundingClientRect();
var frame = aNode.ownerDocument.defaultView;
box.x = rect.left + frame.scrollX;
box.y = rect.top + frame.scrollY;
box.width = rect.right-rect.left;
box.height = rect.bottom-rect.top;
// 親フレームの要素を辿っていく。
box.screenX = rect.left;
box.screenY = rect.top;
var owner = aNode;
while (true)
{
frame = owner.ownerDocument.defaultView;
owner = getFrameOwnerFromFrame(frame);
if (!owner) {
// 最上位のフレームまで来てしまったら、仕方ないのでwindowのプロパティを使う。
// でもウィンドウの枠の外側の座標なので、激しくずれる。
box.screenX += frame.screenX;
box.screenY += frame.screenY;
break;
}
if (owner.ownerDocument instanceof Ci.nsIDOMXULDocument) {
// XULのドキュメント中の要素なら画面上の正確な位置を取れる。
let ownerBox = owner.ownerDocument.getBoxObjectFor(owner);
box.screenX += ownerBox.screenX;
box.screenY += ownerBox.screenY;
break;
}
let ownerRect = owner.getBoundingClientRect();
box.screenX += ownerRect.left;
box.screenY += ownerRect.top;
}
}
catch(e) {
}
return box;
}
function getFrameOwnerFromFrame(aFrame)
{
// window.parentでは、<browser type="content"/> の内容の
// フレームからは親を辿れない。
// nsIDocShellTreeItemを経由すれば可能。
var parentItem = aFrame
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIDocShell)
.QueryInterface(Ci.nsIDocShellTreeNode)
.QueryInterface(Ci.nsIDocShellTreeItem)
.parent;
var isChrome = parentItem.itemType == parentItem.typeChrome;
var parentDocument = parentItem
.QueryInterface(Ci.nsIWebNavigation)
.document;
// フレームに結びついてるiframe要素を直接取る方法が分からないので、
// 泥臭い方法を……
var nodes = parentDocument.evaluate(
'/descendant::*[contains(" frame FRAME iframe IFRAME browser tabbrowser ",'+
'concat(" ", local-name(), " "))]',
parentDocument,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
for (let i = 0, maxi = nodes.snapshotLength; i < maxi; i++)
{
let owner = nodes.snapshotItem(i);
if (isChrome && owner.wrappedJSObject) owner = owner.wrappedJSObject;
if (owner.localName == 'tabbrowser') {
let tabs = owner.mTabContainer.childNodes;
for (let i = 0, maxi = tabs.length; i < maxi; i++)
{
let browser = tabs[i].linkedBrowser;
if (browser.contentWindow == aFrame)
return browser;
}
}
else if (owner.contentWindow == aFrame) {
return owner;
}
}
return null;
}
これにさらにborder幅によるズレとかposition:fixed;
の場合への対応とかも盛り込んだ物を、ライブラリにしてみた。見ての通りchrome特権をバリバリに使ってるので、このコードはアドオンの中でしか動かない。画面上の絶対位置が必要になる場面なんてのはアドオンの場合くらいだろうから、別に問題ないと思うけど。
screenX
とscreenY
に相当する値を取るためにけっこう面倒なことをしているので、オーバーヘッドがきっと半端ない。nsIDOMClientRectの持ってる情報だけで済む場合はそれだけ使った方がいいと思う。
ちなみに、安直な発想でXULDocument.getBoxObjectFor.call(HTMLDocument, HTMLElement)
というのも考えてみたけど、これは実際には使えない。残念。
popInが入っているとテキストリンクが動かない、ことの理由はどうも以下の2点によるみたい。
stopPropagation()
しているため、テキストリンクにイベントが渡されなくなっている。stopPropagation()
されない状態にしてテキストリンク側でイベントを拾って処理を行おうとしても、イベント発生時とテキストリンクが処理を行う時とでDOMツリーの構造が微妙に変わっていて、正常に動かない。何か有効な対策が無いか考えてる。
ところでpopInは内部的にjQueryを使ってるようなんだけど、その旨の表記を僕には見つけられなかった。jQueryはMITライセンスとGPLのデュアルライセンスで、MITを選択した場合でもThe above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
(著作権表示とMITライセンスの許諾表示をソフトウェアの全コピーかもしくは重要な箇所で示す必要がある)ということなので、下手したらMITライセンスの違反ということになるような気が…… (一応フィードバックフォームから送ってはみた)
テキストリンクをThunderbirdにもインストールできるようにしたのにAMOのサイト上ではFirefox専用のままになってしまう件についてボヤいたところ、くでんさんに「Bugzillaで言えばいいじゃない」的な指摘を受けたので、確かにその通りだと思って、念のため新しくバグ報告する前に「target」あたりのキーワードで検索してみたら、Adding new compatible application fails when it's the first oneというバグが出てきて、でもFIXEDになってて「おっかしーなー」と思いながら最初に添付されてたスクリーンショットを見てみたら「Add New Application」と書かれたボタンがあって「なんじゃこりゃあああああこんなん見たこと無いぞおおおお?!」と思って、バグ報告しようとした時に「対象アプリケーション」の英語版表記を知りたくて英語ロケールに切り替えた状態になってたままで開発者用ページのトップに移動したら「新しいUIを試してみよう」みたいな今まで見たことない告知が一番上に表示されてて、そこから辿っていったら今テスト中らしい新UIにアクセスできて(新UIはまだ日本語じゃ利用できないようで、日本語に切り替えてアクセスしようとしたら見れなかった)、それを使うと手動で対象アプリケーションを追加できた。
あと、今までは一度アップロードしたバージョンは、ファイルを削除することはできてもその「バージョン」自体を無かったことにはできなかったんだけど、新UIの方ではそういうファイルが無い状態になったバージョンを「削除」する機能も加わってた。やっときたか……ていうかなんで今までできなかったんだ?
テキストリンク バージョン3.1以降で、Thunderbirdでも利用できるようにした。
プレーンテキスト形式のメールでは、Thunderbird自体のURI自動認識の処理を置き換える形で動作する。
Thunderbird本体のURIの認識部分は結構いいかげんなので、地の文とURIが連続してるとたまに酷い事になる。テキストリンク導入後は、Thunderbird自身による抽出結果を一旦全部白紙に戻して、もう一度URIの認識を自力で行うようになる。
同じような事をするアドオンが他にもありそう(っていうかFirefoxではLinkificationがそうだ)だけど、自分では見つけられなかったので……
ところで、AMOの方にもアップロードしたんだけど、過去にFirefox専用として登録したアドオンは後からThunderbirdにも対応した後も、Firefox専用アドオンとして扱われてしまって、Thunderbird Add-onsの方からは辿る事ができないようだ。これってどうにかならんのだろうか。
Tree Style Tabで選択可能な組み込みのスタイル指定の一つとして、Mac OS X上のデフォルトテーマ風の物を、cho45さんのStylish用スタイル定義を参考にして作ってみた。
スクリーンショットはVista上での物だけど、OS X上でも確認はしてるのでご安心を。
Firefox 3以前の環境ではcho45さんのスタイル定義ほぼそのまんまを適用するようになってて、その場合はタブの高さが26ピクセル固定になってしまうのでタブの中に何か追加する系のアドオン(具体的にはInformational Tab)との相性が非常に悪い。
で、それをなんとかする方法として、Firefox 3.5以降ではborder-imageが使えるということを思い出したので、その実験というか練習も兼ねて使ってみる事にした。
普通に考えると、tab要素自体に-moz-border-imageを指定すればそれでおしまいという事になるんだけど……ツリー型タブの場合はドロップ位置のマーカーを表示するためにborderを多用してるので、-moz-border-imageをtabに指定すると都合が悪い(普通のborderと同時に指定した場合、-moz-border-imageの方が優先されるようだ)。かといって、内側や外側にもう一つタブ全体を囲うXUL要素を増やそうとすると、他のスタイル指定と激しく競合して見た目がグチャグチャになるし……
で、色々試行錯誤して、Firefox 3以前でタブの右・左・中央のそれぞれに異なる背景画像を表示するために使っていたボックスを流用して解決する方法を思いついた。
この拡大図で言うと、9個に分けられた各領域を普通だったら一つのボックスのborder-imageでカバーするところを、今回は1~3・4~6・7~9の3つのボックスに分けている。-webkit-border-imageや-moz-border-imageの例として紹介されているコードでは4つの辺の幅を同じにしてる例が多いけど、実は4つの辺はそれぞれバラバラに幅を指定できる。なので、
url("共通の画像") 10 10 10 10 / 10px 0 10px 10px
で右の辺の幅を0に。url("共通の画像") 10 10 10 10 / 10px 0 10px 0
で左右の辺の幅を0に。url("共通の画像") 10 10 10 10 / 10px 10px 10px 0
で左の辺の幅を0に。という風にしてやる事で、1枚の画像で3つのボックスそれぞれに異なる部分を切り出して適用するような効果を得られる。
また、このままだとタブの高さがborder-imageの幅の分だけ高くなってしまう(border-imageの上辺+タブのラベルの高さ+border-imageの下辺=タブの高さ)ので、タブのラベルやアイコンなどに対して上下にネガティブマージンを設定して、強制的にタブの高さを小さくするようにしてみた。上の図は切り出し位置を示すためにわざと高さを広げた状態だけど、ネガティブマージンを効かせれば、冒頭のスクリーンショットのようなスリムなタブになる。
以前、Mac OS X上でタイトルバーとツールバーがくっついた様な見た目を実現するためにFirefox 3から導入されたactivetitlebarcolor属性とinactivetitlebarcolor属性について調べたけど、このあたりの仕組みがFirefox 3.5ではまた変わった。Firefox本体に同梱されるテーマでは上記の仕組みは使われなくなって、代わりに-moz-appearance
プロパティの-moz-mac-unified-toolbar
という値が指定されている。
-moz-appearance: -moz-mac-unified-toolbar
と指定されたtoolbar要素は、外観が自動的にUnified Toolbarになる。-moz-mac-chrome-active
、ウィンドウがアクティブでない時は-moz-mac-chrome-inactive
になる。-moz-appearance: none
等を指定してUnified Toolbarでなくした後も、タイトルバーはUnified Toolbarスタイルのままになる。最後の項の挙動はひょっとしたら今後変わるかもしれない。スタイル指定の意味合い的には、Unified Toolbarが存在しなくなったらタイトルバーの表示も元に戻すべきだろうし。とりあえず2009年3月24日時点のビルドではこうだった、ということで。
ちなみに、activetitlebarcolor属性とinactivetitlebarcolor属性は、今の所はFirefox 3.5でもまだ使えるみたい。
ロージナ茶会ちゃんねる 試作零号 - (そーしゃる+こんぴゅーた)さいえんす→勉強中
要約:「西洋には昔から性に対する本音と建て前があったんだよ! 貞操を守りなさいとか言いながら実は裏ではエロエロで性欲発散する文化があったんだよ! 日本は明治維新で建前だけ輸入しちゃったから性欲発散する場が無くなってしまったんだよ! だから妄想で補うためにエロ漫画やエロビデオが大量に流通してるんだよ!」「な、なんだってー!!!」
動画2つ合わせて2時間オーバー。いやー非常に面白い与太話でした。