2009-12-20
Chrome Keyconfig、Chrome Gestureにアクションを追加する方法:ドラフト
Chrome Keyconfig、Chrome Gesturesにアクションを追加する方法について、AutoPatchWork 1.0.2では、下記のようにした。
Diff of background.html 17f2721ce0 - autopatchwork - Project Hosting on Google Code
var CHROME_GESTURES = 'jpkfjicglakibpenojifdiepckckakgk'; var CHROME_KEYCONFIG = 'okneonigbfnolfkmfgjmaeniipdjkgkl'; var action = { group:'AutoPatchWork', actions:[ {name:'AutoPatchWork.toggle'}, {name:'AutoPatchWork.request'} ] }; chrome.extension.sendRequest(CHROME_GESTURES, action); chrome.extension.sendRequest(CHROME_KEYCONFIG, action);
こんな感じでオブジェクトを渡すと、Keyconfig、Gesturesの設定画面のセレクトボックスにAutoPatchWork.toggleとAutoPatchWork.requestが追加される。ユーザーがそれを選択し、どこかのページでそのアクションを呼び出すとその名前のEventが発行されるようにしている。
Gesturesの場合、こんな感じ。
var ev = document.createEvent('Event'); ev.initEvent(act.name, true, false); ev.direction = GM._directionChain; ev.action = act; document.dispatchEvent(ev);
Keyconfigの場合、timesはviモードを有効にしている場合に5 jと押すと5が入る。
var ev = document.createEvent('Event'); ev.initEvent(act.name, true, false); ev.key = key; ev.action = act; ev.times = KC._times||KC.times||1; ev.target = target; document.dispatchEvent(ev);
これらのEventオブジェクトに付けたプロパティは、拡張同士だと参照可能だけど、ページ側からは見えないようになっています(今のところ)。
で、とりあえずはこれで使えそうな気がするけど、ちょっと問題がある。
というのも、AutoPatchWorkからsendRequestするタイミングがシビアで、起動時に登録を失敗することがあるみたい。しかも、AutoPatchWorkの有効・無効を切り替えると、アクションが増えてしまう…。
このへん、スマートな解決方法がなさそうでどうしたものかなと悩み中です。
Constellation2009/12/21 18:18登録が成功したか, KeyConfigがinstallされているかなどがわかるとありがたいので, callbackを呼んでいただけるとありがたいです. (成功しなかった場合は自前で準備など...)
2009-06-02
parseIntRight
JavaScript | |
less - id=”id-1234”からIDを抜き出すjQueryプラグイン
getIdだとId自身を取得すると思ってしまう。やってることはparseIntを逆から処理する感じなので、reduce/reduceRightに倣って、parseIntRightってメソッドを定義するのが良いのではないか。
ただ、parseIntRightなら aaa0xFF な文字列にも対応したいところだけど、その辺は妥協…
2009-06-01
Dev版Chrome用UserScripts
Google Chrome, UserScripts | |
Dev版だと、Google Chrome 2.0 で使える(自作の) User Scripts - 0xFFが動かなかったりするので、
に置いてある。
破壊的な配列走査
JavaScript | |
配列の各要素を書き換えたい場合、Array#mapを使うのが一般的だと思う。
var array = new Array(500).join(',').split(','); array = array.map(function(a,i,ar){ return i; });
map自体は破壊的ではないので、代入し直さないといけないのが煩わしい。
それならこう書くのもありではないか。
array.forEach(function(a,i,ar){ ar[i] = i; });
うん、こっちのほうが速そう。(滅多に使われない)第3引数の配列自身を使えばなかなか汎用的。
というわけで、軽くベンチ。
んー、微妙にmapよりは速いけど、体感的な差が出ることはなさそうな誤差レベルな感じ。
というわけで、好みの問題かな。
2009-05-26
Re:文字列中に含まれる文字を除外した英数字を取得
ハッシュバージョン
(function(_s){ var _a = _s.split(''), hs = {}, res = [], i, s, l; for(i=0,l =_a.length;i<l;i++) hs[_a[i]]=true; for(i=48; i<58; i++){ /*0-9*/ s = String.fromCharCode(i); if (!hs[s]) res.push(s); } for(i=65; i<91; i++){ /*A-z*/ s = String.fromCharCode(i); if (!hs[s]) res.push(s); s = String.fromCharCode(i+32); if (!hs[s]) res.push(s); } return res; })('234DEFxyz');
正規表現でもいけそう
2009-05-18
SITEINFOチェックの高速化
oAutoPagerize | |
Cookieを使うようにしたらoAutoPagerizeが速くなるんじゃないかと思ったけど、そんなに速くならなかったので埋葬 - 言いたい放題 - チーム俺等
「正規表現を全部コンパイル」していたのは、 url を | でつなげて1つの正規表現にして、対応サイトではないという判定を1回のチェックで行おうとしていたときの名残でした。
正規表現が長くなりすぎて Safari でエラーになるようになってしまったので、一回チェックは諦めたのだけど、折角なのでその代替案を考えてみた。
といっても、たいしたものではなく、SITEINFOファイルの作成時に、urlをあらかじめ6000文字くらいずつ繋げたものを用意しただけ。
http://ss-o.net/userjs/test/oAutoPagerize.js
http://ss-o.net/userjs/test/0AutoPagerize.SITEINFO.js
これでSITEINFOにマッチしないページでの処理が少し早くなる、はずです。
ちなみに、最初全部のurlを繋げていたら、hAtomはどのURLにもマッチするように書いてあったから、結局必ずマッチしちゃって意味がなかった(から短いものは省くようにした)。
ただ、0AutoPagerize.SITEINFO.jsがサイズ的に結構大きくなるし、そこまで劇的な効果があるわけではないからやはり採用は見送ろうと思う。
oAutoPagerize.jsは実行される回数が多くて、こういう小手先の最適化も試す価値はあると思うんだけど、バランスが難しい。