ラベル Google Chrome の投稿を表示しています。 すべての投稿を表示
ラベル Google Chrome の投稿を表示しています。 すべての投稿を表示

2011年1月12日水曜日

[Google] H.264サポート打ち切るなんてマジ狂っとる

[The Chromium Blog] HTML Video Codec Support in Chrome

でもって、WebMに移行しろとかゆってはります。マジワロスw。この愚行にはJohn Gruberもさっそく噛み付き、5つの疑問を投げかけとります。
  1. 「H.264はオープンイノベーションを阻害するからサポートやめる」とかゆってるクセに、ChromeはクローズドソースでプロプライエタリなFlashプラグインをバンドルしとるやんけ。ほんならH.264と同様にFlashもサポートすんのやめるんやろな?やめんゆうならその理由をゆうてみぃや。
  2. AndroidでもH.264サポートしとるな。これもやめるんやろな?やめんゆうならその理由をゆうてみぃや。
  3. あんたんとこのYouTubeでもH.264つこてるな。これ全部WebMで再エンコするちうことになるんやで。オープンイノベーションという大義名分のためなら、H.264サポートはやめてええちうわけやな?そんなことせぇへんゆうんやったらその理由をゆうてみぃや。
  4. Netflix、Amazon、Vimeo、MLBといったストリーミングビデオ各社に対し、H.264に加えてWebMも対応したデュアルエンコードにしてくれと要求するちうことやな?せやないとChromeユーザはH.264コンテンツを視聴する場合、Flash Playerに頼らざるを得んようになるんやけど、マジどうするん?
  5. これって誰得?
ちうことで、まぁ、またGoogleのたわごとかいなwちう感じなんで、放置でおkっす。WebPとか使ってるの見た事無いしーw。私のこれまでの主張はこんな感じですし、これ以上コーデック増やすなボケとしか言い様がないんですわマジでw

2010年10月1日金曜日

[Google] バカの一つ覚え

[Chromium blog] WebP, a new image format for the Web

ネタが尽きてくるとこういった小手先の最適化に逃げるしか手が無くなる。つまらんネタでも出し続けるあたり、相変わらずの自転車操業ということらしい。汚れ仕事ばかりやらされるとチームは腐るよ。鼻の利くヤツはすり潰される前に逃げ出すんで、そろそろ数字にも現れてくるんじゃないかな。

2010年6月26日土曜日

[Google Chrome] バカの一つ覚え

[The Chromium Blog] A fresh coat of chrome

Appleが1ボタンマウスに拘りすぎてUXを犠牲にしてしまったという歴史を彼らは知らないようだ。ミニマリスムとは「少なければ少ない程良い」という安易な思想では、断じて、無い。

あいかわらず肝心な事については気付かない間抜けさ加減。速度なんて時間が経ちゃイヤでも上がるものなのにそれをコアコンピタンスにしちまうなんて正気の沙汰じゃねぇ。

2010年6月8日火曜日

[Programming] Safari Extension を作ってみた

Google Chrome に見切りを付けた私といたしましては渡りに舟ということで、早速、手を出してみました。まだ大雑把にしか把握してませんが、流石はWebKitベースという事で、アーキテクチャが Chrome Extension にそっくりです。
  • Global HTML は Chrome で言うところのバックグラウンドページ
  • injected Scripts → content_scripts
  • Extension Bar → ブラウザアクション
  • dispatchMessage → chrome.extension.sendRequest
  • info.plist → manifest.json
といった感じですね。

試しに作ってみたのは、ページ内の単語やフレーズをGoogle翻訳、アルク、Urban Dictionaryといった辞書サイトに渡して新規タブにて表示するというものです。マウスで単語を選択しコンテキストメニューからどの辞書サイトを呼ぶかを選ぶようにしています。


構成は Global HTML と injected script の組み合わせという事になります。以下は現状のソースです。

global.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript" charset="utf-8">
function initAll() {
safari.application.addEventListener(
"command",
function(event) {
safari.application.activeBrowserWindow.activeTab.page.dispatchMessage(event.command);
},
false
);
}
</script>
<title>test - Global HTML page</title>
<body onload="initAll();">
</body>
</html>

injected.js
safari.self.addEventListener(
"message",
function(msg) {
var w = document.getSelection().toString();
switch (msg.name) {
case "google":
window.open("http://translate.google.co.jp/?hl=ja&tab=wT#en|ja|" + encodeURIComponent(w), "_blank");
break;
case "alc":
window.open("http://eow.alc.co.jp/" + encodeURIComponent(w) + "/UTF-8/?ref=sa", "_blank");
break;
case "ud":
window.open("http://www.urbandictionary.com/define.php?term=" + encodeURIComponent(w), "_blank");
break;
}
},
false
);

info.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDisplayName</key>
<string>lookup</string>
<key>CFBundleIdentifier</key>
<string>com.yourcompany.lookup</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>Chrome</key>
<dict>
<key>Context Menu Items</key>
<array>
<dict>
<key>Command</key>
<string>google</string>
<key>Identifier</key>
<string>google</string>
<key>Title</key>
<string>Google翻訳</string>
</dict>
<dict>
<key>Command</key>
<string>alc</string>
<key>Identifier</key>
<string>alc</string>
<key>Title</key>
<string>アルク</string>
</dict>
<dict>
<key>Command</key>
<string>ud</string>
<key>Identifier</key>
<string>ud</string>
<key>Title</key>
<string>Urban Dictionary</string>
</dict>
</array>
<key>Global Page</key>
<string>global.html</string>
</dict>
<key>Content</key>
<dict>
<key>Scripts</key>
<dict>
<key>Start</key>
<array>
<string>injected.js</string>
</array>
</dict>
</dict>
<key>ExtensionInfoDictionaryVersion</key>
<string>1.0</string>
<key>Permissions</key>
<dict>
<key>Website Access</key>
<dict>
<key>Level</key>
<string>All</string>
</dict>
</dict>
</dict>
</plist>

なんといってもコンテキストメニューがさっくり使えるのがうれしいですな。まだ設定画面等については未調査ですが、ざっくりと見た感じでは Chrome Extension よりも使い出がありそうです。機能拡張ビルダーまわりは、まだまだこなれてないようで良く落ちるんですが、まぁこれはそのうち改善されるでしょう。そういえば「拡張機能」じゃなくて「機能拡張」なんすよね。INIT/cdev時代を知るものにとっては、やっぱり「機能拡張」の方がしっくり来るんですわw

処理の流れとしては
  1. コンテキストメニューからどのサイトを開くかを選択するコマンドを発行
  2. Global HTML がコマンドを受信
  3. Global HTML はページ内コンテンツにアクセス出来ない(つまりページ内の単語やフレーズが拾えない)ので injected script に対して dipatchMessage を発行し、その際にパラメータとしてコマンドを引き渡す
  4. injected script は document.getSelection() により、ページ内の単語やフレーズを取得し、コマンドに応じたサイトのURL を生成し、window.open(url, "_blank") により新規タブでページを開く
という感じです。

ちなみに window.open()でタブを開いているので、ポップアップが禁止されていると(「Safari→ポップアップウィンドウを表示しない」にチェックが入ってると)ページが開きません。これは問題ですね。これを回避する為には safari.self.browserWindow.openTab() といった Window/Tab 関連の新規 API を呼ぶしか無いようですが injected scripts からはこれらの API が呼べないようです。ということは、injected scripts から Global HTML に URL を渡す dispatchMessage を発行するってことですか。結構めんどくさいかもw


追記: Global HTML 側で openTab() を呼び出すように変更。それほど面倒じゃないですね。アプリとコンテンツの分離という観点からすれば、これはこれで一貫性があると言えましょう。

global.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript" charset="utf-8">
function initAll() {
safari.application.addEventListener(
"command",
function(event) {
safari.application.activeBrowserWindow.activeTab.page.dispatchMessage(event.command);
},
false
);
safari.application.addEventListener(
"message",
function(msg) {
var newTab = safari.application.activeBrowserWindow.activeTab.browserWindow.openTab();
newTab.url = msg.name;
},
false
);
}
</script>
<title>test - Global HTML page</title>
<body onload="initAll();">
</body>
</html>

injected.js
safari.self.addEventListener(
"message",
function(msg) {
const pattern = {
google: "http://translate.google.co.jp/?hl=ja&tab=wT#en|ja|{}",
alc: "http://eow.alc.co.jp/{}/UTF-8/?ref=sa",
ud: "http://www.urbandictionary.com/define.php?term={}"
};
safari.self.tab.dispatchMessage(pattern[msg.name].replace("{}", encodeURIComponent(document.getSelection().toString())));
},
false
);

2010年4月24日土曜日

[Google Chrome] 何故そこまで拘る?

例のpkasting氏のコメントによると、
all the changes, from hiding http to changing the theme color to changing the shortcut keys, will be returning to the Dev channel in a few weeks and we'll have the M6 cycle to tweak, fix, experiment with, and evaluate them.
とのことで、version 6でまたこの「改悪」が復活する模様。うむ、これで決定だ。もう二度とChromeをインストールする事はあるまい。この手のインチキデザイナーが幅を利かすようになったらプロジェクトはオシマイだよ。

2010年4月23日金曜日

[Google Chrome] それなら最初からマージすんなよ

[Google Chrome Releases] Dev Channel Update
Various UI features related to the url bar/ omnibox have been removed from this release (e.g. http:// truncation, star icon, etc...)
とのことなんだがイシューリストには4月14日にWontFixでクローズされたという表示が残っているだけ。なにそれ、閣内不一致ってやつですか。いくらdev版とはいえそりゃ無いだろ、何のためのメーリングリストだよ。とりあえずやって見て、怒られたらやめるっていう手法が通じるようなプロジェクトじゃないんだからさ。

Chromeは削除済みなので私にはもう関係無いんですけど、ネタとしては面白いんでGoogle Chrome Releasesブログは今後も購読させていただきます。ネタとして聖教新聞とってるヤツの気持ちがよくわかりましたわw

2010年4月21日水曜日

[Google Chrome] やってらんねー

AdDictというChrome拡張機能を公開していたのだが、Chrome開発陣の腐れっぷりに愛想が尽きたので公開を停止しギャラリーからも削除した。この問題への対応を見て、Chrome開発陣の性根が良くわかりましたんでね。なかでも、pkasting@chromium.orgなる人物の発言には、正直言って、目を疑った。「ウチは民主主義じゃねぇんだよ(キリッ」ってアンタねw。どんだけ自分とこのUIに自信があるかは知らんが、でけぇ口たたくのはApple以上のUXを提供出来るようになってからにしてくれや。

Flash統合の件なんかもそうなんだが、Googleはどんどん、技術主導の会社から政治主導の会社に変貌しつつある。俺たちゃそんなアバズレにゃ興味ねぇよ。「マップリデュース!」の呪文で俺たちをメロメロにさせたGoogleたんはどこに行っちまったんだ。

今回の件にしても、WebKit2の発表にビビって、慌てて付け焼き刃のしょーもない変更を加えただけなんじゃね?という印象がある。そこにはポリシーもなければテクノロジーも無い。ただ不毛で下衆な対抗心があるだけだ。そんな会社にUXなんて作れるわけねぇだろ。

2010年4月19日月曜日

[Google Chrome] マジでかんべんしてください

Chrome の dev 版なんだが、アドレスバー(omni bar って言うんだっけw)から http:// が抜かれ、
www.google.co.jp/ig?hl=ja
といった具合に表示されるようになった。URL 全体をコピーすると http:// が付加されるようなので、単なる表示上の処理ということになるわけだが、実はちょっと困ったことになっている。

例えば、本来 http://www.google.co.jp/ig?hl=ja となっている URL の http://www.google.co.jp/ だけをコピーするといったことが出来ないのだ。URL の一部分をコピーした場合は http:// が付加されないという仕様になっているらしい。よって http://www.google.co.jp/ というURLにしたければwww.google.com/ をコピーして「手作業で」頭に http:// を付加するしか無い。なんやそれw。正直、ワケわからん。一体、今回の変更には何のメリットがあるんだ?

この変更は既に話題になっており、the NEXT WEB でも紹介されていた。その中で引用されているこの記事を見て更に驚いたのは、今回の変更がもたらしている「ftp スキームな URL における Chrome の奇妙な振る舞い」についてであります。dict スキームな URL を呼び出す拡張機能を作っているわたくしといたしましては大いにビビったわけで、早速チェックしてみたのだが、幸いにも影響は無い模様。おどかさんといてw、で済ませたいところだが、これではっきりしたのは「今回の変更において、スキームの表示に関する明確なポリシーは無い」ということであり「小手先の調整」であるということだ。うーむ、上だけでなく現場も脇が甘くなっちまったのか?

おおかた「Mobile Safari の真似をしてみました」というレベルでしかないんだろう。PC とモバイルをごっちゃに考えているようで、流石は「UI は作れても UX は作れない会社」と言われるだけの事はありますな。議論の舞台となっているイシューリスト41467番もガンガンスレが伸びているんだが、現時点のステータスは「それは仕様です」のまま。あちゃーw

2010年4月6日火曜日

2010年3月7日日曜日

[Programming] Chrome Extension は福袋的にした方が良い?

ここしばらく、ちまちまとChrome拡張機能をいじっております。で、「リンクのターゲットを_blankに書き換える」というありがちな拡張機能を試しに作ってみたわけです。正味の処理は
var l = document.querySelectorAll("a");
for (var i = 0; i < l.length; i++) {
if (!l[i].target) {
l[i].setAttribute("target", "_blank");
}
}
だけという、実にあっさりしたもの。御存知の通りChromeでは各タブおよび拡張機能ごとにプロセスが割り当てられるわけですが、どれくらいメモリ消費してるのかなと思いアクティビティモニタを見たところ

ということで、えらくメモリ食うんだなぁとびっくりいたしました。

確かに Firefox でも OOPP を初めとするプロセス分離作業が進められているわけで、各プロセス毎に分厚い土台を準備しなきゃならなくなるというのも時代の流れなのでしょう。

この驚きはあの時の驚きに似てます。C から C++ に移行した時、バイナリの肥大化にのけぞった時の驚きです。ただの Hello World が iostream にしただけで何でこんなにでかくなるんだよwというやつです。C は高級言語じゃなくて超高級マクロアセンブラだという説を心底納得出来たのもこの時でした。まぁ、libc からこのかた分厚い土台に支えられてきた人間がいまさらメモリ効率がどうこうなんて言えた義理じゃねぇだろ、というのも重々承知ではあるんですけどね。

で、こういった状況を鑑みまするに、今後は単機能な拡張機能を個別に数多く入れるという考え方よりも、色々な機能を詰め込んだ多機能な拡張機能を一つだけ入れるという考え方の方がメモリ効率的に良いということになります。「福袋的」というのはそういうことです。要るか要らないかは置いといて、とりあえず色々詰め込んどけという手法です。

でもやっぱりこの手法には違和感を感じざるを得ないんですわ。小人さんがわらわらと群がり手を取り合って仕事するというファンタジー的・明治合体チョコボール的世界、すなわち、コマンドをパイプでちまちまとつないでいく世界を知っている人間からしてみれば、上で述べたような福袋的アーキテクチャは「何このゴリアテw」「かっこ悪〜」となるんじゃないでしょうか。

2010年2月20日土曜日

[Google] Chrome Extension を作ってみて

やっぱWebKit系もやっとかんとね、ということでGoogle Chromeのdev版を入れてみたのですが、やはり気になるのは拡張機能の作りやすさ。ということで実際に作って確かめるためにこんなのを作ってみたわけです。

で、結論としては「Firefox(というかXUL)でExtensionを作っている人やGreasemonkeyでページをいじっている人にとってはストレスがたまるのでは?」という感じです。

content_scriptsの制限のきつさ
XMLHttpRequestもlocalStorageも直接には使えず、すべてbackground_pageを別途作製してsendRequestもしくはconnectしないと使えない、というのは異常に思えます。せっかくmanifest.jsonにpermissions設定があるのですからXMLHttpRequestくらいは直に使えるようにしてほしいところです。まぁcontent_scripts程度であればGreasemonkeyのChrome版でGM_系APIが実装されるまで待てということでいいんじゃないでしょうか。

コンテクストメニューへのアイテム追加などが出来ない

すくなくともドキュメントを見た範囲では出来ないようで、これはかなり痛い。UIをいじりたければWebKit APIを使えと言うことなのでしょうか。いずれにしてもXULのオーバーレイという一貫した設計思想とはかけ離れているようなので、また勉強し直しですな。

XUL慣れしているとかえってイライラする

これもGoogle側にしてみれば「おれにいわれてもなぁ」なので、仕方ないっちゃ仕方ないんですけどね。たとえば右クリックされた単語を拾うならばdocument.popupRangeParentとdocument.popupRangeOffsetを使うという定石がFirefoxでは使えるわけですが、Chromeではそんなプロパティは無いわけで、DOM Rangeで書き直しすることになりそうです。他にも「XULなら出来るのに」というのがどんどん出てくるんじゃないでしょうか。

まぁ「まだこなれていないだけだから気長にいこう」というのもアリなわけで、しばらくはちまちまと楽しませていただくことにします。