最近火狐輸入法事件的變更
u881831
我研究了一下輸入相關事件，
下面是以輸入 "中" 為例每按一個鍵之後所觸發事件以及文字實際輸入的順序：
FF8 and before
keydown
compositionstart
ㄓ
text
ㄓㄨ
text
ㄓㄨㄥ
text
中
text
text
input
compositionend
keyup
FF9 and FF10
keydown
compositionstart
compositionupdate
ㄓ
text
compositionupdate
ㄓㄨ
text
compositionupdate
ㄓㄨㄥ
text
compositionupdate
中
text
text
input
compositionend
keyup
FF11
keydown
compositionstart
compositionupdate
text
ㄓ
compositionupdate
text
ㄓㄨ
compositionupdate
text
ㄓㄨㄥ
compositionupdate
text
中
text
compositionend
input
keyup
FF12
keydown
compositionstart
compositionupdate
text
ㄓ
input
compositionupdate
text
ㄓㄨ
input
compositionupdate
text
ㄓㄨㄥ
input
compositionupdate
text
中
input
text
compositionend
input
keyup
附帶一提以"a" 為例輸入英文字的情況是：
keydown
keypress
a
input
keyup
也就是說，
FF9 新增compositionupdate 事件，其他事件沒有變化；
FF11的text事件移到文字輸入之前而且input 事件移到compositionend之後，
我們沒用到text事件，
input 事件沒有和compositionend直接相關所以順序沒影響；
不過FF12又在文字輸入之後觸發input 事件，
這就造成目前版本無法使用輸入法輸入文字。
在FF8 之前input 事件只會在輸入英文以及輸入法完成輸入文字時觸發，
所以之前就在這個事件觸發時將輸入區文字送出去並清空輸入區。
不過FF12每按一個鍵就會觸發input 事件，
所以第一個鍵會送出第一個注音符號並清空輸入區，
在輸入未完成時清空輸入區會讓輸入法無法工作所以接下來的按鍵都沒有反應。
之前我在做GC移植的時候，
我把compositionstart起到compositionend之間的input 事件都跳掉不處理，
這個做法在FF12可以正常工作，
不過在FF10及先前版本input 事件是在compositionend之前，
所以輸入區文字不會送出也不會清空。
我在pref_test 這個branch內的修改部分如下：
--- termview.js
+++ termview.new.js
@@ -38,6 +38,7 @@
var composition_start ={
view: this,
handleEvent: function(e) {
+ this.view.isComposition = true; // Fix for FX 12+
this.view.onCompositionStart(e);
}
};
@@ -47,6 +48,13 @@
view: this,
handleEvent: function(e) {
this.view.onCompositionEnd(e);
+ delete this.view.isComposition; // Fix for FX 12+
+
+ // For compatibility of FX 11 and before
+ if(e.target.value) {
+ this.view.onTextInput(e.target.value);
+ e.target.value='';
+ }
}
};
this.input.addEventListener('compositionend', composition_end,
false);
@@ -62,6 +70,8 @@
var text_input={
view: this,
handleEvent: function(e) {
+ if(this.view.isComposition) // Fix for FX 12+
+ return;
if(e.target.value) {
this.view.onTextInput(e.target.value);
}
我的做法是跳掉composition之間的input 事件，
並且在compositionend事件觸發時送出輸入區文字並清空，
這種做法接近FireBBS.l-hedgehog對輸入法的處理。
英文字和原來一樣使用input 事件處理，
輸入法就和FireBBS.l-hedgehog一樣使用compositionend，
這樣就能兼容所有FF版本。
不過這種做法和先前相比複雜了一點而且也不知道我沒測試過的輸入法能不能用，
不知道各位有沒有更好的方法？
我想我們應該在FF12正式版出來以前釋出相容的版本，
我等一下會先把v0.2.5以後輸入法以外的錯誤修正部分先整合到trunk ，
我想我們也可以討論看看新版還要放什麼東西。
u881831
所以現在已經有一些災情傳出來了。
我已經將我之前的patch 整合到trunk 並且把版本號更新，
接下來建立Tag 並且上傳打包好的檔案到這邊的Downloads 還有AMO 就完成了。
不過因為最近的更新只有我一個人在弄，
我也沒有收到任何錯誤回報或是意見回饋，
我想就這樣發布正式版應該很危險。
pcman 或是其他committer 如果有時間的話可以幫忙測試一下這個版本嗎？
也歡迎其他有意願的使用者幫忙測試。
這是我包好的檔案：
https://docs.google.com/open?id=0B-K9h3GKW2VGNDZkZjNkMmYtMWYyMC00NmQ5LWE0ZGMtOWIxMzYwZTQwMGFh
如果最後不需要修改的話這個檔案就會是正式版。
因為這邊的處理可能會花一些時間，
再加上AMO 版本更新可能要一個多星期，
遇到問題的使用者可以先下載上面連結的檔案。
因為這次的版本更新主要都是錯誤修正並沒有太大的變動，
我想應該不會出現太嚴重的錯誤。
這次更新的詳細修正項目如下：
r117 Show favicon in search menu
r121 Add ")" to link detection rule
r123 Fix some warnings from AMO
r124 Fix selTrim bug
r125 Fix a minor bug of selectAll
r126 Fix scrolling bug
r131 Disable copy in Firefox menu when nothing is selected
r133 Fix a bug of receiving tab char
r142 reconnection is limited to 100 times
r143 delay for reconnection is implemented (no delay by default)
r144 Fix IME bugs in FX 12+
SUN Chun-Yen
PCMan
u881831
也許可以把輸入控制字元的部分也包進去，（onkeyPress）
也就是把所有中英文輸入的部分包在一起。
畢竟這兩個部分在跨瀏覽器時都遇到事件觸發實作方式不同的問題。
在GC控制字元不會觸發keypress事件，
所以之前幾乎是整個重新設計控制字元的部分，
因為當初沒有整個重寫所以那部分的程式碼也是很糟糕。
如果想要保留onkeyPress原來架構的話，
我也許可以重寫出一個在FX和GC都可以正常執行的版本，
這樣控制字元的輸入也就沒那麼必要一起封裝起來了。
另外我目前輸入法的實作並沒有特別去偵測FX版本，
不管在新版還是舊版的FX裡面都是：
input 事件處理英文、
compositionend處理中文。
只是FX11以後版本的compositionend之後會立刻觸發input 事件，
所以compositionend那邊的註解只是標記我們將來停止支援10esr 之後
該段程式碼就可以移除了。
至於跨瀏覽器的部分，
因為GC的事件是非同步的，
compositionend後面的input 不會等前面的執行結束才執行，
所以這兩個函式都會送出輸入的字串，
造成我們所輸入的文字會出現兩次。
這部分我還沒找出方法解決，
可能還是要獨立封裝起來然後在內部偵測瀏覽器。
On 4月26日, 上午12時09分, PCMan <pcman...@gmail.com> wrote:
> 感謝你的貢獻!!
> 剛剛在看你的 code，
> 我有個想法：
> 要不要把整個輸入法處理，封裝成一個 InputHandler 物件？
> 把這些髒髒的 hack 封裝起來，維持 termview.js 的乾淨，
> 這對於維持 termview.js 可讀性，以及之後要移植到其他瀏覽器，應該會有幫助。
> 對應不同版本的Fx可有不同內部實作，但是InputHandler物件對外的介面保持一致。
>
> 2012/4/25 u881831 <u881...@hotmail.com>
>
>
>
>
>
>
>
> > FX12正式版發布了，
> > 所以現在已經有一些災情傳出來了。
> > 我已經將我之前的patch 整合到trunk 並且把版本號更新，
> > 接下來建立Tag 並且上傳打包好的檔案到這邊的Downloads 還有AMO 就完成了。
> > 不過因為最近的更新只有我一個人在弄，
> > 我也沒有收到任何錯誤回報或是意見回饋，
> > 我想就這樣發布正式版應該很危險。
> > pcman 或是其他committer 如果有時間的話可以幫忙測試一下這個版本嗎？
> > 也歡迎其他有意願的使用者幫忙測試。
> > 這是我包好的檔案：
>
> >https://docs.google.com/open?id=0B-K9h3GKW2VGNDZkZjNkMmYtMWYyMC00NmQ5...
WM
拜託快送去審核吧，PTT瀏覽器板一直有人問Orz
另外可以請問一下Chrome那邊的進度如何了？有辦法用Native Client API 來做了嗎？
u881831於 2012年4月27日星期五UTC+8上午12時11分48秒寫道：
u881831
至於輸入控制字元的部分因為當初有考慮到跨瀏覽器的問題，
GC的程式碼可以在FX正常執行，
不過那部分程式碼需要重新整理，
我想這邊就用FX舊有的程式碼，
因為我接下來比較忙過一陣子再來處理這些程式碼。
如果這次的修改沒有問題的話我想應該就可以送到AMO 了。
On 5月4日, 下午9時37分, WM <wander...@gmail.com> wrote:
> 我在Linux上測過了，沒有問題。
>
> 拜託快送去審核吧，PTT瀏覽器板一直有人問Orz
>
> 另外可以請問一下Chrome那邊的進度如何了？有辦法用Native Client API 來做了嗎？
>
Chrome版的部分目前還在內部測試的階段，
最主要的問題是設定flash 連線模組的部分，
目前的模組無法分辨連線失敗是沒有網路、網址打錯還是沒有設定安全性設定所造成的，
所以除非使用者有相當程度的網路相關知識可以自行除錯，
目前這個套件對大部分使用者來說還是不大好用，
我對flash 這部分不熟接下來也沒時間處理所以短時間內應該不會有改善，
我想這個問題解決之後再加上一些介面文字的潤飾應該就能出正式版了。
至於Native Client 的外掛程式也是在GC的沙盒中執行，
所以跟javascript程式碼一樣無法建立任意的socket，
也就是說無法連線到一般的BBS 站。
PTT 上有人提到的Secure Shell使用了GC的私有API ，
這個API 限定只有這個套件才能使用，（鎖套件ID）
雖然說他們有給開發人員測試用的ID，
不過我想我們不應該直接使用這個ID發佈正式版。
這邊是那個套件的常見問題
http://goo.gl/3LROU
以及開發人員指南（和原始碼的連結）
http://goo.gl/UoE2e
將來的GC新增了可以使用上述API 的白名單，
http://code.google.com/p/chromium/issues/detail?id=111314
至於這個功能會不會也只是內部使用就不知道了。
如果可以像flash 一樣由使用者新增白名單項目，
就有轉換成Native Client 的價值了。
Native Client 外掛程式為了提升效能在不同的CPU 架構下不能重複使用，
不過只要編譯x86 和x86_64兩個版本應該就能在所有主流的桌上型作業系統上使用，
而且包含我在內應該有不少人C++ 比Flash 熟的，
如果有人現在想要試試看的話我也不反對。
u881831
應該要要發布新版了。
不過....
這個星期mozilla 改了一個API ，
所以在FX 15a1 nightly 裡顯示模組掛了。
nsIUTF8ConverterService.convertStringToUTF8
的參數由三個變成四個：
http://mxr.mozilla.org/mozilla-central/source/intl/uconv/idl/nsIUTF8ConverterService.idl
相關討論串：
https://bugzilla.mozilla.org/show_bug.cgi?id=663057
該次修改的diff：
http://hg.mozilla.org/mozilla-central/rev/3e58342de10e
要修正的話很容易就是在所有用到convertStringToUTF8 的地方再加一個參數，
對14以前的舊版本而言應該沒有副作用，
至於那個新增參數aAllowSubstitution 的值對我們來說應該沒有太大的影響。
只不過我並不確定FX15到正式版為止還會不會改，
有沒有必要現在就修正？
還是不管它我們這邊直接出新版，
等FX15正式版出了再說？
不知道各位有什麼想法？
> 這邊是那個套件的常見問題http://goo.gl/3LROU
SUN Chun-Yen
u881831
等待審核區位置18x 似乎會等很久？
convertStringToUTF8 和這次修正的IME 問題不一樣，
Mozilla 應該可以把第四個參數設為optional來達到向下相容，
暫時先靜觀其變吧。
On 5月25日, 下午9時26分, SUN Chun-Yen <scy.h...@gmail.com> wrote:
> 謝謝你。我個人認為先推出目前的版本以配合 12-14，15到時再說。
>
> 2012/5/25 u881831 <u881...@hotmail.com>:
>
>
>
>
>
>
>
>
>
> > 現在輸入法那邊的程式碼已經重整完畢，
> > 應該要要發布新版了。
> > 不過....
> > 這個星期mozilla 改了一個API ，
> > 所以在FX 15a1 nightly 裡顯示模組掛了。
>
> > nsIUTF8ConverterService.convertStringToUTF8
> > 的參數由三個變成四個：
> >http://mxr.mozilla.org/mozilla-central/source/intl/uconv/idl/nsIUTF8C...
u881831
接下來是FX15的相容性問題，
使用者應該會一連上BBS 就立刻斷線。
FX15進aurora channel後依然沒有解決，
我先修改pref_test 讓它相容於FX15（也相容舊版本）
如果各位有什麼想法也可以及早提出。
另外我之前修正選取區域的時候沒有處理好，
當選取區域的結尾在最後一個column的時候，
選取區域的結尾會設成錯誤的值。
因為像是純文字複製等功能有包含自動修正的機制，
所以我沒有發現這個問題。
但是pref_test 的複製ANSI彩色功能沒有做自動修正所以就出錯了，
GC版也有一樣的問題。
我已經將修正過後的程式碼上傳到trunk 和所有的branches了，
我想trunk 部分的修正應該不會對trunk 現有的功能造成影響。
造成各位的困擾實在是很抱歉
u881831
也許我們應該先規劃新版本會比較好，
我想新版本要是只有這個修正的話有點少，
所以我想讓這個套件安裝時不須重新啟動就能執行。(bootstrap)
基本上這個套件不能直接在bootstrap 模式使用的有：
overlay
resourceURI
components
其中overlay 的部分似乎要改用document.loadOverlay()，
但是unload很麻煩：
https://bugzilla.mozilla.org/show_bug.cgi?id=607384
不過我們似乎只有在FX 3.6用到這部分，
而bootstrap 要在FX4+以上才能用，
所以這部分先不管。
至於第二部分可以藉由註冊自己的resource protocol解決，
第三部分可以把component 包成module後載入，
下面是我試出來的.xpi：（convertStringToUTF8 尚未修正）
https://docs.google.com/open?id=0B-K9h3GKW2VGM0ZGYnNXbGQ5dmc
事實上我做的事就只有在這兩個檔案各加一行
install.rdf:
<em:bootstrap>true</em:bootstrap>
components/TelnetProtocol.js:
var EXPORTED_SYMBOLS = ['Protocol'];
以及從這個套件複製出bootstrap 設定檔
https://addons.mozilla.org/en-US/firefox/addon/pdfjs/
然後修改套件名稱檔案路徑而已，
不知道會不會有版權問題所以暫時沒有上傳到repository，
如果大家覺得還好那我就先上傳以後再改。
（抱歉最近沒有太多時間處理程式碼）
因為只有在FX10（包含 ESR）以及更新版本才會自動讀取
bootstrap 套件的 chrome.manifest並自動忽略不支援的指令，
所以FX 4 ~ FX 9 都不能使用，
但是FX 3.6不認得bootstrap 所以完全不受影響。
如果要支援FX 4 ~ FX 9 這些版本可能要寫不少程式碼，
不知道有沒有辦法只讓FX 4 ~ FX 9 需要重新啟動？
還是要直接捨棄FX 9以前版本的相容性？
因為我對bootstrap 並不是很熟，
這也只是初步試出來的結果不知道會不會造成其他問題，
不知道大家有什麼意見？
另外也希望大家幫忙測試看看有沒有什麼問題。
u881831
所以我暫時先把這個修改放到pref_test 這個branch內，
等到確定之後再放到trunk ，
如果不打算加入這個修改就回朔先前版本或移除index.rdf 的標記。
另外先前的測試套件因為不知道會不會有版權問題所以移除。
我想主要的問題是：
以後的overlay 需要手動一個一個移除新增的Node, js, css 等；
捨棄FX 4 ~ FX 9 的相容性，FX 3.6還相容但是可能也要捨棄，
這樣錯誤主控台出現的警告都可以修掉。
目前的pref_test 還沒拿掉FX 3.6的相容性，
所以FX 4 ~ FX 9 可以安裝但是完全不能用，
不知道使用FX 4 ~ FX 9 的人多不多說不定可以完全不管。
其他的應該都不會太麻煩，
而且即使不改成不須重新啟動，
我想也應該要在結束時清理物件，
除了可以降低發生錯誤或是和其他套件相衝的機率，
也可以減少記憶體洩漏的情況，
雖然之前有試著處理這部分，
不過也沒有辦法保證都有處理到。
版權的部分我想這樣應該就沒有問題了，
我還加上了版本升級時的處理：
GC會在套件升級時關掉所有套件開啟的分頁；
FX則是什麼都不做繼續用舊版套件運行。
一般而言應該要做成像GC一樣清除所有套件造成的影響，
這樣比較不會出問題也比較方便後續的開發，
不過我這邊是做成升級時重載分頁然後使用新套件重新連線，
移除時清空分頁但不關閉，
以後重裝套件後可以用上一頁回復分頁，
我想這樣應該有比較好的使用者體驗。
如果之後發現這樣會出問題再照正規寫法關閉所有分頁。
附帶一提保護分頁的部分也許會在這邊出問題，
因為我對這邊不熟所以沒有處理，
如果這部分確定進trunk 的話，
希望有人可以幫忙處理這部分。
不知道各位有沒有什麼想法，
希望可以提出來討論。
On 6月18日, 下午10時08分, u881831 <u881...@hotmail.com> wrote:
> 因為FX15進aurora channel後convertStringToUTF8 依然沒有變更，
> 也許我們應該先規劃新版本會比較好，
> 我想新版本要是只有這個修正的話有點少，
> 所以我想讓這個套件安裝時不須重新啟動就能執行。(bootstrap)
>
> 基本上這個套件不能直接在bootstrap 模式使用的有：
> overlay
> resourceURI
> components
>
> 其中overlay 的部分似乎要改用document.loadOverlay()，
> 但是unload很麻煩：https://bugzilla.mozilla.org/show_bug.cgi?id=607384
> 不過我們似乎只有在FX 3.6用到這部分，
> 而bootstrap 要在FX4+以上才能用，
> 所以這部分先不管。
>
> 至於第二部分可以藉由註冊自己的resource protocol解決，
> 第三部分可以把component 包成module後載入，
> 下面是我試出來的.xpi：（convertStringToUTF8 尚未修正）https://docs.google.com/open?id=0B-K9h3GKW2VGM0ZGYnNXbGQ5dmc
>
> 事實上我做的事就只有在這兩個檔案各加一行
>
> install.rdf:
> <em:bootstrap>true</em:bootstrap>
>
> components/TelnetProtocol.js:
> var EXPORTED_SYMBOLS = ['Protocol'];
>
> 以及從這個套件複製出bootstrap 設定檔https://addons.mozilla.org/en-US/firefox/addon/pdfjs/
> ...
>
> 閱讀更多 >>
u881831
u881831於 2012年6月24日星期日UTC+8下午4時28分04秒寫道：
u881831
PPAPI 實作的外掛程式會被GC的安全性政策限制住，
所以只有GC白名單內的程式才能建立不受限的TCP socket。
（例如Google自己的Secure Shell）
GC21內建了兩個版本的Flash ，
一個是PPAPI 另一個是傳統的NPAPI ，
預設是使用PPAPI 的版本所以這個套件不能連線，
在網址列輸入about:plugins
點選詳細資訊後將類型是PPAPI 的Shockwave Flash 停用，
這樣就可以連線了。
要是將來的版本沒有內建NPAPI 的Flash，
我想應該可以到Adobe 網站自行安裝，
因為只有GC支援PPAPI 所以Flash 應該不會停止支援NPAPI 的版本。
不過使用NPAPI 繞過GC的安全機制是有風險的，
其他的Flash 應用程式有可能會對各位造成損害，
目前不建議一般使用者用這個方法繞過安全性限制。
因為找出不能連線的原因所以之前放出的測試版連結作廢，
manifest version 2的部分併入SVN 內，
另外R155起參考Google Secure Shell 實作了GC本身書籤的支援，
不過和FX不一樣的是這些書籤限定使用目前的套件，
換一個BBS 套件或是將來的新版換了ID後這些書籤就不能用了。
現在遇到的問題都暫時繞過去了，
不過現在Google的安全性政策愈來愈緊縮，
非web store 的套件將來可能會將近無法使用，
NPAPI 外掛的限制也有可能愈來愈嚴格。
雖然之後應該還是會有類似開發人員模式的方法繞過去，
不過這樣會讓使用者暴露在安全性風險中。
因為我們的套件不符GC的安全性規範，
我想Google可能不會讓我們的套件上架，
就算編譯自己的NPAPI 外掛可能也不行。
這樣的話這個套件還有繼續維護的價值嗎？
另外pref_test 這個branch的偏好設定架構我應該不會再更動了，
有沒有人有意願review？
u881831於 2012年8月2日星期四UTC+8上午2時20分29秒寫道：
PCMan
不管怎麼說，把 BBS 放在瀏覽器裡面，
還是很多人喜歡的功能。
如果內建 flash 不能用，
逼不得已，還有幾個方法
1. NaCl? 這個我不確定
2. 實作 PPAPI plugin
3. 用 proxy, 在 localhost 額外跑一個 proxy server, 轉到
telnet，這有點小題大作，但是好不容易開發到今天這樣，不能用很可惜，我們還是可以再想辦法。
2012/8/4 u881831 <u88...@hotmail.com>:
u881831
以後要使用這個套件可能要另外安裝NPAPI 版本的flash 了。
NaCl和內建的Flash 都是基於PPAPI 技術實作的，
所以使用NaCl或其他PPAPI plugin也會遇到和內建Flash 一樣的問題。
我所知道比較可行的方案之一是使用他人開發基於NPAPI 的技術，
像是java或是目前套件所使用的flash ，
缺點就是需要另外安裝外掛而且還要應付他們自己設定出來的安全性限制。
另一個方案就是自己編譯NPAPI 的外掛，
雖然可以不用考慮上面提到的安全性限制，
不過各個平台需要各自編譯自己的外掛，
我應該沒有時間去維護這個部分。
至於未上架擴充套件的問題，
這一次更新似乎沒有看到變動。
就我所知非官方有上架的類似套件似乎都是由開發團隊建立proxy server來實作，
我們應該沒有能力做這種事，
所以這部分可能要先擱置。
附帶一提，
要安裝NPAPI 的flash 除了到adobe 官網上下載安裝程式安裝外，
也可以將dll 丟到GC主程式資料夾內，
把npswf32.dll丟到chrome.exe同目錄下Plugins 子目錄內就可以了。
（沒有那個目錄的話就自己新建）
以portableapps製作的可攜版GC為例，就是把flash 的 dll檔案丟到：
可攜版根目錄\App\Chrome-bin\Plugins
雖然安裝版也可以這麼做，
不過除了測試各種版本flash 的開發測試人員外，
一般使用者還是建議使用Adobe 官方提供的方法來安裝NPAPI 版的flash 。
PCMan於 2012年8月4日星期六UTC+8下午11時55分06秒寫道：
PCMan
https://developer.chrome.com/apps/app_network.html#connecting
http://blog.alexmaccaw.com/chrome-tcp-udp
google還附有一個 telnet 的範例!!!
https://github.com/GoogleChrome/chrome-app-samples/tree/master/telnet
這個應該就是解決之道了！
看起來 Chrome 未來將會提供內建的 raw TCP socket 給 extension 用 :-)
2012/9/28 u881831 <u88...@hotmail.com>:
u881831
雖然標experimental的API 依然需要使用者作一些設定才能用，
不過跟現在的flash 相比還是好很多，
而且這個API 將來也有可能去掉experimental標籤。
不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
目前使用Flash 實作的功能除了socket外還有編碼轉換，
雖然編碼轉換的功能應該可以直接用內建的PPAPI flash ，
不過flash 內似乎也沒有直接的轉換API ，
轉換的功能也是用數個API 組合出來，
再加上flash 和javascript之間的資料傳遞，
所以目前的編碼轉換很慢。
我這邊有想到用HTML本身的API 組合出編碼轉換的方法，
不過速度上可能不會比現在快。
不知道大家有沒有更好的方法？
還是沿用現有的flash API ？
除了上面這些，目前還有一些待改善的問題，
在支援GC本身書籤後我之前做的下拉選單就沒有存在必要了；
registerProtocolHandler 沒有進展而omnibox keyword 有很多問題，
弄成APP 然後在web 頁面用html元件拼出自己的網址列，
也許會有比較好的使用者體驗？
右鍵選單似乎只能控制個別套件的子選單，
而且那個API 的目的似乎是要服務所有HTML頁面，
就我們的需求而言，
似乎禁用原有選單然後用HTML元件拼出右鍵選單才是比較正確的做法？
還有一些比較不重要的問題：
右鍵搜尋的部分我還找不到API 來實作；
訊息通知音目前使用tts 實作，但是Linux 下沒有tts 可以用，
其他類似軟體都是用在extension內放mp3 等檔案，
也許我們可以把開放版權的聲音檔案包進這個套件？
自動登入的帳號密碼目前也還沒找到比較安全的儲存方法。
下面是剛剛提到純HTML的編碼轉換：
big5char.htm
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<script type="text/javascript" src="big5char.js"></script>
<title>Big5 code converter</title>
</head>
<body>
<!-- Necessary elements for u2b api -->
<form id="u2b_form" action="u2b.htm" target="u2b_frame" accept-charset="big5">
<input type="hidden" id="u2b_ustr" name="u2b_ustr">
</form>
<iframe name="u2b_frame" style="display:none;"></iframe>
<!-- The example for these api, not necessary elements -->
<form>
<p>Hexadecimal charCodes of big5 characters. For instance, a4a4</p>
<textarea id="big5code" rows=10 cols=80></textarea><br /><br />
<input id="b2u" type="button" value="b2u">
<input id="u2b" type="button" value="u2b">
<p>Chinese words within Big5 charset. For instance, 中</p>
<textarea id="unicode" rows=10 cols=80></textarea><br /><br />
<input type="reset">
</form>
</body>
</html>
big5char.js
window.onload = function(event) {
document.getElementById("b2u").onclick = b2u;
document.getElementById("u2b").onclick = u2b;
document.getElementById("u2b_form").callback = u2b_callback;
}
function b2u(event) {
//var data = "a4a4"; // originally data is "\xa4\xa4"
var data = document.getElementById("big5code").value;
var result = [];
while(data.length>1) {
result.push(parseInt("0x"+data.substr(0,2)));
data = data.substr(2);
}
window.URL = window.URL || window.webkitURL;
var bb = new Blob([new Uint8Array(result)], { "type" : "text\/plain" });
var url = window.URL.createObjectURL(bb);
var req = new XMLHttpRequest();
req.open("GET", url, false);
req.overrideMimeType("text/plain;charset=big5");
req.send();
document.getElementById("unicode").value = req.responseText;
//return req.responseText;
}
function u2b(event) { // asynchronous function
//var data = "\u4e2d";
var data = document.getElementById("unicode").value;
document.getElementById("u2b_form").locked = true;
document.getElementById("u2b_ustr").value = data;
document.getElementById("u2b_form").submit();
}
function u2b_callback(search) { // callback from the asynchronous function u2b
var data = unescape(search.substr(10));
var result = "";
for(var i=0; i<data.length; ++i)
result += ("0"+data.charCodeAt(i).toString(16)).substr(-2);
document.getElementById("big5code").value = result;
delete document.getElementById("u2b_form").locked;
//return result; // originally return data
}
u2b.htm
<html>
<head>
<script type="text/javascript" src="u2b.js"></script>
</head>
<body>
</body>
</html>
u2b.js
window.onload = function(event) {
if(location.search && parent)
parent.document.getElementById('u2b_form').callback(location.search);
}
PCMan於 2012年9月29日星期六UTC+8下午12時24分25秒寫道：
WM
PCMan
> socket API看起來應該可以替代現有的flash 連線，
> 雖然標experimental的API 依然需要使用者作一些設定才能用，
> 不過跟現在的flash 相比還是好很多，
> 而且這個API 將來也有可能去掉experimental標籤。
我也覺得很有可能，都已經給這麼多範例了，還有人開始在利用這個做 extension
但是他的使用方法和 Fx 的差異不小，可能我們需要包裝一下
弄一個我們自己的 socket class，把 Fx 和 GC 的差異封裝起來
> 不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
>
> 目前使用Flash 實作的功能除了socket外還有編碼轉換，
> 雖然編碼轉換的功能應該可以直接用內建的PPAPI flash ，
> 不過flash 內似乎也沒有直接的轉換API ，
> 轉換的功能也是用數個API 組合出來，
> 再加上flash 和javascript之間的資料傳遞，
> 所以目前的編碼轉換很慢。
你要轉換什麼編碼？如果是 big5 to Unicode, 我記得我們有寫過啊？
那個 unicode 補完支援，不就有對照表可以查？
Firefox 裡面用 js 實做不會很慢喔，GC 應該只會更快
需要的話我可以來做這塊。
還是你講的是不一樣的東西？
> 我這邊有想到用HTML本身的API 組合出編碼轉換的方法，
> 不過速度上可能不會比現在快。
> 不知道大家有沒有更好的方法？
> 還是沿用現有的flash API ？
>
> 除了上面這些，目前還有一些待改善的問題，
> 在支援GC本身書籤後我之前做的下拉選單就沒有存在必要了；
> registerProtocolHandler 沒有進展而omnibox keyword 有很多問題，
> 弄成APP 然後在web 頁面用html元件拼出自己的網址列，
> 也許會有比較好的使用者體驗？
這也是一個選項，先求功能正確，再求完美整合啊
> 右鍵選單似乎只能控制個別套件的子選單，
> 而且那個API 的目的似乎是要服務所有HTML頁面，
> 就我們的需求而言，
> 似乎禁用原有選單然後用HTML元件拼出右鍵選單才是比較正確的做法？
同意，而且我們應該不太需要原本右鍵選單裡面的功能。
> 還有一些比較不重要的問題：
> 右鍵搜尋的部分我還找不到API 來實作；
> 訊息通知音目前使用tts 實作，但是Linux 下沒有tts 可以用，
> 其他類似軟體都是用在extension內放mp3 等檔案，
> 也許我們可以把開放版權的聲音檔案包進這個套件？
這是很合理的作法，聲音檔案去 pidgin / libpurple 裡面抓現成的就好了，
很容易解決
> 自動登入的帳號密碼目前也還沒找到比較安全的儲存方法。
個人覺得不需要，在畫面上寫清楚是明碼儲存就好了。
telnet 本來就是毫無安全性的東西，密碼輸入也是以明碼送出到網路，
有心人要竊取非常容易。
再者，如果有人可以進你的電腦，開啟你的設定檔來看密碼，
那他還有什麼其他不能做的事？甚至可以裝 key snooper，
看 BBS 密碼算小事了。
u881831
PCMan於 2012年10月3日星期三UTC+8上午11時58分46秒寫道：
2012/10/2 u881831 <u88...@hotmail.com>:
> socket API看起來應該可以替代現有的flash 連線，
> 雖然標experimental的API 依然需要使用者作一些設定才能用，
> 不過跟現在的flash 相比還是好很多，
> 而且這個API 將來也有可能去掉experimental標籤。我也覺得很有可能，都已經給這麼多範例了，還有人開始在利用這個做 extension
但是他的使用方法和 Fx 的差異不小，可能我們需要包裝一下
弄一個我們自己的 socket class，把 Fx 和 GC 的差異封裝起來> 不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
>
> 目前使用Flash 實作的功能除了socket外還有編碼轉換，
> 雖然編碼轉換的功能應該可以直接用內建的PPAPI flash ，
> 不過flash 內似乎也沒有直接的轉換API ，
> 轉換的功能也是用數個API 組合出來，
> 再加上flash 和javascript之間的資料傳遞，
> 所以目前的編碼轉換很慢。你要轉換什麼編碼？如果是 big5 to Unicode, 我記得我們有寫過啊？
那個 unicode 補完支援，不就有對照表可以查？
Firefox 裡面用 js 實做不會很慢喔，GC 應該只會更快
需要的話我可以來做這塊。
還是你講的是不一樣的東西？
目前的套件已經實作了這個功能。
所以我在想有沒有辦法完全捨棄flash 但是保留現有的功能，
如果使用純HTML的話我想應該會有效能的提升吧。
目前我試出的方法最大的問題是unicode 轉Big5的函式是asynchronous，
不過套件裡有用到u2b 的就貼上彩色文字以及純文字貼上鍵盤輸入兩個地方，
都是要往socket送資料，
這個動作本來就是asynchronous。
因為我之前有做編碼轉換結果的緩存，
所以當緩存裡面找不到的時候進行asynchronous轉換並終止函式，
每隔一小段時間重送，
等到轉換結果進緩存再將資料送到socket就可以了。
也就是說即使使用asynchronous u2b轉換也不需要大改程式架構，
不過如果可以用synchronous 轉換的話程式架構會比較簡潔易讀。
至於Big5的話因為要支援UAO 所以一定要內建編碼表，
所以就不需要考慮這些問題，
UTF8編碼的話單就轉換而言很容易只是termbuf 架構要改。
然後將選取的文字用選中的搜尋引擎搜尋，
目前GC內建的搜尋引擎除了Google自己外還有Yahoo!和Bing，
而目前的套件只是開一個新分頁而已：
http://www.google.com/search?q=%s
沒有辦法抓取其他搜尋引擎。
u881831
u881831於 2012年10月3日星期三UTC+8下午10時23分42秒寫道：
PCMan於 2012年10月3日星期三UTC+8上午11時58分46秒寫道：2012/10/2 u881831 <u88...@hotmail.com>:
> socket API看起來應該可以替代現有的flash 連線，
> 雖然標experimental的API 依然需要使用者作一些設定才能用，
> 不過跟現在的flash 相比還是好很多，
> 而且這個API 將來也有可能去掉experimental標籤。我也覺得很有可能，都已經給這麼多範例了，還有人開始在利用這個做 extension
但是他的使用方法和 Fx 的差異不小，可能我們需要包裝一下
弄一個我們自己的 socket class，把 Fx 和 GC 的差異封裝起來> 不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
GC23雖然可以認出manifest裡面的socket的權限，
但是因為這個API 限定dev channel 才能使用所以無法執行，
看來到stable channel能用為止還有得等。
另外這個文件似乎還沒跟上程式碼的變化：
https://developer.chrome.com/apps/app_network.html#connecting
這邊有該文件Reviewer的意見：
https://chromiumcodereview.appspot.com/10908045
也就是說UDP 範例程式碼所使用的onEvent 似乎已經被棄用，
https://chromiumcodereview.appspot.com/10273016
目前看到的範例套件都沒有使用這個功能，
所以我們可能需要想一想FX內監聽socket事件的函式要怎麼移植。
我直接執行範例套件得到一些初步的結論：
onStartRequest
應該可以直接由連線的callback函式確認result >= 0 後直接呼叫。
onDataAvailable
只能用setInterval 或是其他方法不斷的呼叫read，
當有資料時再呼叫這個函式。
這部分對程式效能有非常重大的影響，
間隔太長的話反應很慢，
太短的話主程式呼叫函式次數太多可能會拖慢速度，
可能要仔細想一想要怎麼做。
onStopRequest
根據socket API的文件，
我們只能從read和write 的回傳狀態碼得知是否已斷線，
要是已經斷線的話WriteInfo 會是{bytesWritten: -15} ，
ReadInfo是{data: ArrayBuffer, resultCode: -15}，
至於連線中而且沒有新資料的時候resultCode是-1。
同樣的這個也需要不斷的呼叫read或write 。
總而言之，以目前API 的功能應該可以取代原有的flash socket，
但是目前這個API 似乎還沒成熟，
也許之後resultCode會變動或是出現更好的監聽socket事件的方法。
我覺得至少要到stable channel能夠使用後再實作比較有意義，
現在實作的話有可能會碰到API 改變而需要大幅改寫程式碼的情況。
不過要是有人想要先試試看的話，
應該可以由官方範例以及這邊提供的資訊做出完整的功能。
PCMan
>> PCMan於 2012年10月3日星期三UTC+8上午11時58分46秒寫道：
>>>
>>> 2012/10/2 u881831 <u88...@hotmail.com>:
>>> > socket API看起來應該可以替代現有的flash 連線，
>>> > 雖然標experimental的API 依然需要使用者作一些設定才能用，
>>> > 不過跟現在的flash 相比還是好很多，
>>> > 而且這個API 將來也有可能去掉experimental標籤。
>>>
>>> 我也覺得很有可能，都已經給這麼多範例了，還有人開始在利用這個做 extension
>>> 但是他的使用方法和 Fx 的差異不小，可能我們需要包裝一下
>>> 弄一個我們自己的 socket class，把 Fx 和 GC 的差異封裝起來
>>>
>>> > 不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
>
> 周末的時候試了一下，
> GC23雖然可以認出manifest裡面的socket的權限，
> 但是因為這個API 限定dev channel 才能使用所以無法執行，
> 看來到stable channel能用為止還有得等。
對，但至少未來當 flash 完全不能用的時候，socket API 應該已經成熟
> 另外這個文件似乎還沒跟上程式碼的變化：
> https://developer.chrome.com/apps/app_network.html#connecting
> 這邊有該文件Reviewer的意見：
> https://chromiumcodereview.appspot.com/10908045
>
> 也就是說UDP 範例程式碼所使用的onEvent 似乎已經被棄用，
> https://chromiumcodereview.appspot.com/10273016
> 目前看到的範例套件都沒有使用這個功能，
> 所以我們可能需要想一想FX內監聽socket事件的函式要怎麼移植。
>
> 我直接執行範例套件得到一些初步的結論：
>
> onStartRequest
> 應該可以直接由連線的callback函式確認result >= 0 後直接呼叫。
>
> onDataAvailable
> 只能用setInterval 或是其他方法不斷的呼叫read，
> 當有資料時再呼叫這個函式。
> 這部分對程式效能有非常重大的影響，
> 間隔太長的話反應很慢，
> 太短的話主程式呼叫函式次數太多可能會拖慢速度，
> 可能要仔細想一想要怎麼做。
這個不會很困難，當 socket.connect() 之後，在 connect Callback 裡面，
呼叫 readNext(); // 在下面定義
function readNext() {
socket.recv(id, 4096, readCallback);
}
然後定義
function readCallback(readInfo) {
if(readInfo.resultCode > 0) {
onDataAvailable(readInfo.data);
setTimeout(0, "readNext()"); // 利用 setTimeout 0 秒
}
}
這樣就可以了，不需要 setInterval()。
每次讀取完一次資料，就再讀下一次，直到 resultCode = -15，就斷線。
如此可以簡單模擬出原來的架構，而且效能搞不好不差？
可以試試看
u881831
http://u881831.blogspot.com/2012/10/bbs-addon-for-google-chrome.html
一般使用者只需要看最後一段的安裝方法就可以了。
關於GC版本的圖示，
目前16x16 的圖示檔我直接拿firefox 版的用，這邊應該沒有問題；
48x48 的我把PCMan novus 網站上的 logo.gif 轉成PNG 來用，之後也許會出問題；
128x128 的我沒有放所以套件安裝時的提示視窗就沒有套件的圖示。
Google Chrome 對圖示的規定如下：
https://developers.google.com/chrome/web-store/docs/images
不過我覺得暫時不需要遵守那邊的規定，
等以後有打算上架的時候再看看有沒有人要畫，
目前應該可以用類似這邊的圖檔：
http://moon.cse.yzu.edu.tw/~s922254/pcman_icons/
不知道有沒有人有48x48 和128x128 大小的原始檔案？
另外關於偏好設定的程式碼，
因為FX內建API 不是很方便，
所以有一些地方的程式碼變得很冗長，
如果把整個架構重作，
像GC版本一樣用localstorage配合JSON儲存設定，
應該可以大幅簡化程式碼，
不知道大家有沒有什麼意見？
我可能會先實作在GC版本，
如果OK的話再弄到FX branch ，
最後 trunk 先整合偏好設定系統，
已實作偏好設定就再說。
PCMan於 2012年10月9日星期二UTC+8下午10時23分58秒寫道：
u881831
u881831於 2012年10月26日星期五UTC+8下午9時50分43秒寫道：
u881831
u881831於 2012年10月30日星期二UTC+8上午12時03分54秒寫道：
u881831
修復不同分頁間包含ANSI彩色碼的複製貼上；
還有Linux 下使用文泉驛字型時文字下方被切掉，
微米黑的情況比正黑輕微。
這次修正改用垂直置中的方式描繪文字，
微米黑有在正中央但是正黑還是有一點偏高，
比較正確的作法是量字高然後改變行高，
因為會大量修改顯示模組所以暫時用置中的方式處理。
（附帶一提正黑的一些big5符號為全寬字而微米黑為半寬字，所以正黑的ANSI圖表現較好）
這邊稍微總結一下待辦事項：
socket api
GC 24 stable釋出後再處理。
以下的部分比較重要但是工程浩大所以暫時不會處理：
registerProtocolHandler
如果一直沒辦法實作的話，
可能要把BBS 及GC一般網頁的所有telnet的超連結改成套件網址。
無法從網址列取得焦點
可能要實作自己的網址列，
在這個情況下把架構從套件改成APPS會比較好，
另外改成APPS的話需要128*128 的icon。
右鍵選單項目藏在子選單內
這邊可能也是需要用html元件實作出自己的選單，
這樣也能解決Linux 下需要雙擊右鍵才能打開選單。（和手勢功能相衝)
以下是一些小問題也是暫時不會處理：
自訂手勢
工程浩大....
訊息通知視窗不會自動消失
可能需要實作自己的通知視窗，
另外Linux 下如果要使用訊息通知音可能需要安裝TTS 聲音套件，像是
https://chrome.google.com/webstore/detail/us-english-female-text-to/pkidpnnapnfgjhfhkpmjpbckkbaodldb
加密自動登入的帳號密碼
對telnet這種未加密連線而言沒有太大意義，
因為目前沒有內建API ，
自己實作加密的話意義不大。
列出GC內的搜尋引擎
目前只有使用google搜尋BBS 內的關鍵字，
不能使用縮網址還原之類的搜尋引擎，
可能還是要另外實作自訂搜尋。
存取本機檔案系統的文件
因為安全上的限制目前使用上下傳的方式存取本機文件，
用起來很不方便，
可能要等GC實作專供套件的API 。
我覺得我們不應該使用繞過安全性限制的方法，
將來那個方法被封住的可能性很高。
非同步的unicode 轉ansi相容編碼
big5使用內建編碼表所以沒有這個問題，
gb2312等其他編碼也只能看看之後有沒有想到更好的方法。
文字翻譯說明文件等等
等到主要問題解決再處理。
u881831於 2012年11月30日星期五UTC+8上午2時05分34秒寫道：
u881831
u881831於 2012年12月13日星期四UTC+8上午1時34分53秒寫道：
u881831
u881831於 2013年1月20日星期日UTC+8下午8時36分07秒寫道：
解決了上面提到的那些偏好設定系統產生的問題，
這邊使用了GC 20+新增的datalist元件取代原來版本的Omnibox 網址列，
和原來版本一樣可以自動補完站台的網址也可以列出站台列表。
站台列表以前一樣會自動抓存在偏好設定內的站台。
下載網址還是：
https://docs.google.com/file/d/0B-K9h3GKW2VGbUJrWHJZSkVOTTQ/edit
因為我不認為繼續開發這個版本有太大的意義，
之後可能不會再維護。
目前這個版本算是有把原有功能完全移植過去了，
應該可以作為開發類似程式的參考。
PCMan
我本來發起這個專案，其實也是半實驗性質，
希望做為類似程式的參考，
事實上這幾年在醫院工作，我自己已經沒上BBS了，
不知道現在實際還在使用BBS的人口有多少？
但不管怎麼說，有一個這樣的專案展示 javascript 新技術，
還是很有意義的，所以還是很感謝你所做的開發.
BTW, 我們要不要把你完成的 chrome 版，
公開發布出去？例如 web store?
2013/3/13 u881831 <u88...@hotmail.com>:
>
> ---
> 您已訂閱「Google 網上論壇」的「pcmanfx」群組，因此我們特別傳送這封郵件通知您。
> 如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 pcmanfx+u...@googlegroups.com。
> 如需更多選項，請前往：https://groups.google.com/groups/opt_out。
>
>
PCMan
有沒有什麼方法可以把那個BBS視窗塞到 chrome 的分頁裡面？
在我這裡測試是自己獨立的視窗，這是刻意的嗎？
2013/3/14 PCMan <pcma...@gmail.com>:
u881831
事實上不只是界面和瀏覽器主視窗分開，
獨立視窗和主視窗之間的資料傳遞也有很嚴格的限制。
我想應該是安全的考量吧，
一般網頁不可以進行不受限的TCP 連線。
我之所以會不想繼續開發這個版本也是因為這個限制。
另外如果要公開發布的話，
我想至少要有像pcman lite和pcmanx的分頁，
用html元件拼出分頁的界面其實不算太麻煩，
只是程式架構可能要大改才能同時進行多個連線，
我想我應該不會去處理這個部份。
PCMan於 2013年3月14日星期四UTC+8下午12時39分34秒寫道：
PCMan
透過 Chrome messaging APIs
這裡有範例
https://github.com/GoogleChrome/chrome-app-samples/tree/master/messaging
extension 和 packaged apps 之間可以互相呼叫
所以我可以把主程式放在 extension 內，
並且建立一個 helper app 專責處理 TCP connection
當 extension 開了新分頁，要建立連線時，
傳送一個訊息到 packaged app，由 app 進行 socket 操作，
然後把結果以 response 回傳給 extension
就可以完全繞過 GC 的限制，而且只用純 javascript
我有實際試過，這個方法是可以從 extension call app 內的 socket API
pcman 套件內呼叫 chrome.socket.* 的地方很少，
只要稍做封裝，把這幾個 calls 改成 messages 轉發到另一個 helper app
再從 helper app 內代為呼叫 chrome.socket 並且傳回結果給 extension
就可以實現了。而且剛好因為 socket API 都是 async 的方式，
和 messaging API 完全一樣，所以實現起來非常簡單。
基本上，只會用到 extension to app 單向的簡單訊息傳輸
如果有必要，甚至 helper app 也可以反向傳訊息呼叫 extension
例如要求 extension 開啟 new tab
唯一的缺點是，helper app 需要使用者手動執行，
因為新版 GC 已經取消 packaged app 的 background_page 了，
看起來必須手動啟動才行，好像不能從 extension 內呼叫起動?
any ideas?
2013/3/14 u881831 <u88...@hotmail.com>:
u881831
PCMan於 2013年4月11日星期四UTC+8下午1時14分56秒寫道：
我終於找到一個有趣的方法可以繞過 GC 的限制
透過 Chrome messaging APIs
這裡有範例
https://github.com/GoogleChrome/chrome-app-samples/tree/master/messaging
extension 和 packaged apps 之間可以互相呼叫
所以我可以把主程式放在 extension 內，
並且建立一個 helper app 專責處理 TCP connection
當 extension 開了新分頁，要建立連線時，
傳送一個訊息到 packaged app，由 app 進行 socket 操作，
然後把結果以 response 回傳給 extension
就可以完全繞過 GC 的限制，而且只用純 javascript
我有實際試過，這個方法是可以從 extension call app 內的 socket API
pcman 套件內呼叫 chrome.socket.* 的地方很少，
只要稍做封裝，把這幾個 calls 改成 messages 轉發到另一個 helper app
再從 helper app 內代為呼叫 chrome.socket 並且傳回結果給 extension
就可以實現了。而且剛好因為 socket API 都是 async 的方式，
和 messaging API 完全一樣，所以實現起來非常簡單。
基本上，只會用到 extension to app 單向的簡單訊息傳輸
如果有必要，甚至 helper app 也可以反向傳訊息呼叫 extension
例如要求 extension 開啟 new tab
唯一的缺點是，helper app 需要使用者手動執行，
因為新版 GC 已經取消 packaged app 的 background_page 了，
看起來必須手動啟動才行，好像不能從 extension 內呼叫起動?
any ideas?
而且為了處理多個BBS 分頁的情況，
程式架構會變得很複雜。
如果讓helper app藉由extension 的background_page 開啟瀏覽器分頁，
應該就不會有剛剛那些問題。
只是這樣做的話，
和現在的版本比起來就只有不用寫自己的分頁介面，
沒有辦法使用像是瀏覽器書籤之類的元件，（使用flash 的舊版本已經有這個功能）
和現有的版本比起來似乎沒有好上多少。
不知道大家有沒有什麼意見？
另外在FX版本上最近有一些變更，
首先在未啟用Direct2D的windows 電腦上，
FX 21 不再有ClearType (anti-aliasing) 效果。（影響範圍未確認）
應該只有較舊的電腦會受影響，
這邊應該不會去處理。
再來是Firegestures從1.7.1 起不會在xul 頁面的canvas元件上面作用，
https://github.com/gomita/firegestures/commit/14a6d0fdd4c44c198b16c8f07df5c3ea1e42689e
也就是說pref_test 這個branch的手勢功能必須在畫面邊緣才會啟動。
因為這邊不可能修改Firegestures的程式碼，
所以可能的處理方式就是把GC版本的獨立手勢功能移植回來，
不過目前GC版本的手勢功能還很陽春，
而且和其他手勢套件的衝突也是一個很麻煩的問題；
再不然就是把xul 介面改成html，
只是這樣要大改程式架構所以應該不會這麼做。
關於這部分不知道大家有沒有什麼意見？
Ett Chung
把xul改成html會動到滿多東西的，
目前還有一部份人在使用的pcmanfx-unofficial版就是html的版本了。
當時是因為在xul上出了這個問題:
http://forum.moztw.org/viewtopic.php?f=18&t=31814
後來我就改成html了，記得改的時候有些發生一些排板問題，
不過因為是很久以前改的，所以已經忘記是遇到啥問題了。
如果能在維持xul的情況下修正應該會比較好。
有去看過FireGestures是改了哪個部份造成失效的嗎？
Ett Chung
r164加入了 <html:div> 這組標籤後就完全可以用，那其實就維持現狀就好了。
Ett Chung
u881831
u881831於 2013年5月16日星期四UTC+8下午2時19分12秒寫道：
PCMan
今年開始Google開始剔除NPAPI 的外掛程式了，我這邊按照先前PCMan 的想法先弄一個packaged app處理socket，加上自動啟動和隱藏UI後使用者體驗的部分算是可以接受了。
只是像這樣在GC的安全性機制打洞，不只是上傳google play 可能會被刪除，將來版本的GC會不會對這個動作設限也不知道。
我想這個版本應該能撐個一兩年吧。
除了從svn 下載外，封裝好的主程式可以從這邊下載：處理socket的app 除了從svn 下載外，還可以從這邊下載：https://drive.google.com/file/d/0B-K9h3GKW2VGb3dUdjlvRXBvcjQ這個app 有白名單的設計，白名單預設是空的所有套件都不能使用。套件和app 都裝好之後，第一次使用前請手動啟動app ，出現設定視窗後請手動填入主程式的套件ID。主程式的套件ID可以在GC的擴充功能設定頁找到。技術上將填入套件ID的動作寫死在程式碼裡面是很容易，不過目前這個套件還是處於開發中的狀態，所以在安全性的考量下，我就設計成必須手動填入名單，這樣的話其他開發者應該可以直接把這個app 套用在他們修改過的程式，另外像是ssh 等不同功用的套件應該也能直接用這個app 進行開發。
u881831
PCMan於 2014年1月15日星期三UTC+8下午2時08分32秒寫道：
2014/1/12 u881831 <u88...@hotmail.com>今年開始Google開始剔除NPAPI 的外掛程式了，我這邊按照先前PCMan 的想法先弄一個packaged app處理socket，加上自動啟動和隱藏UI後使用者體驗的部分算是可以接受了。你太厲害了，我之前試驗一下弄不出來就沒弄了居然真的被你做出來了!!!剛試用過，相當棒！太厲害了！BTW, 那個 about 頁面改一下吧，其實現在大部份都是你做的了把你自己的名字放前面吧，我的丟下面就好 :)只是像這樣在GC的安全性機制打洞，不只是上傳google play 可能會被刪除，將來版本的GC會不會對這個動作設限也不知道。我之前有私下 mail chrome developers 問相關問題沒有獲得這方面的保證。google play 的條款並沒有禁止這種應用套件之間互相溝通，也是chrome 允許的合法機制，而非用 plugin 繞過我倒是覺得可以上架看看，如果真的不允許，再來看怎麼弄上架費用我可以負責出我想這個版本應該能撐個一兩年吧。如果撐不住，我還有想好三個備案1. 開發 pepper API 為底的 plugin，專門提供 TCP socket 連線功能給 javascript。plugin 只做 socket 操作，這樣開發應該不難。2. 用 node.js 寫一個小 proxy server，讓使用者另外下載安裝，跑在 localhost。於是，chrome 套件是連 http://localhost/，然後由 server 轉用 raw socket 連外，兩者之間訊息用 json 互傳即可，都 js 寫起來應該很簡單。缺點是，server 接收到BBS站更新畫面，好像沒有好方法可以主動通知我們的 client? 如果用 websocket 而不是 http，這問題就沒了，但 node.js 弄 websocket 似乎比較麻煩？3. 徵求善心人士提供一台 proxy server 讓我們連 http 轉 socket (例如某些學術網路)
2. 網路上 node.js & websocket 應該有不少現成的程式，
直接從那邊改的話應該不會太困難。
只不過這個方法需要另外裝本機應用程式，
這部分可能會讓部分使用者卻步。
3. 基於安全的理由，我想應該不會有網管會同意不特定的使用者進行不受限制的連線，（不限 IP 和 port ）
而且基本上學網是不能架 open proxy 的。
我想等到真的被 GC 封鎖的時候應該是好幾年後了，
也許到時候還有其他新方法可以用。
除了從svn 下載外，封裝好的主程式可以從這邊下載：處理socket的app 除了從svn 下載外，還可以從這邊下載：https://drive.google.com/file/d/0B-K9h3GKW2VGb3dUdjlvRXBvcjQ這個app 有白名單的設計，白名單預設是空的所有套件都不能使用。套件和app 都裝好之後，第一次使用前請手動啟動app ，出現設定視窗後請手動填入主程式的套件ID。主程式的套件ID可以在GC的擴充功能設定頁找到。技術上將填入套件ID的動作寫死在程式碼裡面是很容易，不過目前這個套件還是處於開發中的狀態，所以在安全性的考量下，我就設計成必須手動填入名單，這樣的話其他開發者應該可以直接把這個app 套用在他們修改過的程式，另外像是ssh 等不同功用的套件應該也能直接用這個app 進行開發。之後如果要上架，還是直接寫死比較安全，以免被濫用。這樣似乎比較不會有安全上的疑慮
目前的版本在 GC 升級重開的時候會自動 launch app ，
然後就彈出 app 的設定視窗。
我這邊有寫當所有 GC 瀏覽器視窗關閉時關閉 app，
似乎是因為 GC 關閉的過程是 non-blocking 的，
所以設定視窗還是會彈出來。
雖然可以暫時設定成 launch app 時不彈出視窗，
只是我覺得使用者手動 launch app 時至少出現一個視窗會比較好。
不過我最近比較忙，接下來可能要到春節才有時間處理了。
u881831
u881831於 2014年1月17日星期五UTC+8上午2時20分05秒寫道：
Google似乎開始緊縮擴充套件政策了：
https://sites.google.com/a/chromium.org/dev/developers/extensions-deployment-faq
目前我們這邊是使用者手動安裝，
不是弄一個可以自動更新的網址，
所以暫時沒有影響，
不過將來也許還是會被限制。
目前比較大的問題算是暫時解決了，
在socket.js 開頭填入PCMan 套件的ID就能直接綁定不讓使用者更改，
其他的像是整理程式碼之類的短時間內應該不會去弄，
也許我們可以開始考慮在Chrome Web Store上架了。
因為我之後可能沒有辦法繼續開發，
所以我沒有打算用我個人的帳號上架。
我想也許可以建立一個公用帳號，
不過因為我沒有將套件上架的經驗，
我不知道這樣做會不會出問題，
像是信用卡號設定等等，
這邊可能要大家一起討論後再決定。
然後看是要用什麼名子上架，
再將about 頁面改一下應該就可以上架了。
u881831
http://blog.chromium.org/2014/02/make-sure-to-get-your-extension-in.html
windows 的使用者目前有兩個暫時的替代方案：
第一個是用開發者模式載入未封裝的extension ，
主程式pcmanfx-gc-0.0.5.170.crx解壓縮載入後，
pcmanfx-gc-socket-0.0.1.170.crx不需解壓直接安裝，
（socket app是屬於apps不是extension 所以暫時沒有被禁）
所以只要在socket app內填入未封裝extension 的id就能和原來一樣使用了，
（未封裝extension 的id是隨機的）
不過每次打開GC時都會跳出警告要你停用未封裝的extension ；
第二個方法是用群組原則安裝套件，
這個方法本來是給大公司或教育機構的網管用的，
我們這邊要另外找一個網路空間放.crx和描述安裝資訊的.xml，
xml 的格式和下面網頁所用的一樣。
https://developer.chrome.com/extensions/autoupdate
這部分我還沒有弄，
假設這部分的網址是
https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml
https://pcmanfx.googlecode.com/files/pcmanfx-gc-latest.crx
xml 的內容是
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='kakincoohepfppgfdfhdbjpmhbelkiho'>
<updatecheck codebase='https://pcmanfx.googlecode.com/files/pcmanfx-gc-latest.crx' version='0.0.5.170' />
</app>
</gupdate>
另外pcmanfx-gc-latest.crx 的manifest.json 也要加入
"update_url": "https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml",
日後更新版本時才會自動更新。
使用者端似乎是先裝完群組原則範本後，
http://allgoogletesting.blogspot.tw/2013/10/install-chrome-group-policy-api-on-windows.html
（非官方網頁）
按照下面的說明在本機群組原則編輯器裡面修改，
http://dev.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist
這邊要填入的值是
"kakincoohepfppgfdfhdbjpmhbelkiho;https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml"
缺點是要解除安裝必須要到本機群組原則編輯器裡面修改。
因為我還沒試過所以還不知道這個方法行不行，
有興趣而且也有適當網頁空間的人可以試一試。
u881831於 2014年2月22日星期六UTC+8下午5時27分43秒寫道：
...
Ett Chung
--
---
這是 Google 網上論壇針對「pcmanfx」群組發送的訂閱通知郵件。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 pcmanfx+u...@googlegroups.com。
如需更多選項，請前往：https://groups.google.com/d/optout。
Ett Chung