是的，delay 跟小灰不一樣，應該分清楚，我只是有點在懷疑，小灰是不是 delay 變嚴重所導致的，因為 delay 時那種狀況跟小灰有點像，只不過 delay 可以恢復，小灰不行。 之前試出一次小灰後，po 了前面那篇，之後我又開了新的 gcin 與 terminal 試看看能不能重現小灰，結果到目前為止還是不能重現，只會明顯 delay，但沒有出現小灰。佈置好 debug 環境想認真看，小灰就躲起來了。 XD 我用行列，有開啟預選字的選項，不常出現小灰，但偶爾還是會出現。還有，我進入 x-window 時有跑 gnome-settings-daemon，不知道這會不會有關係。

「資源」，源有候選字，「源」打完後閃一下，過不久，小灰就出現了！

源→emhf→[1.源 2.鴻]

註：
在這次的測試中，我取消了gtab輸入法設定的兩個選項：
（1）「隱藏第二型（輸入鍵...）」
（2）「輸入鍵顯示移至第一列」
結果小灰還是出現了，看來小灰和這二個選項的關連性不大。

這次我使用了「固定gcin視窗位置」的功能，但小灰還是出現了，看來小灰和這個功能的關連性應該不大。

「知道」，打了「知」，一頓之後，小灰就現身了！

拆碼和候選清單如下（四碼倉頡）：
知→okr→[1.知 2.佑]

coolcd ，
考慮進BIOS把CPU降頻到500MBHz左右或換一台效能差一點的電腦，
可以考慮再多勾個「預覽列中顯示部份符合的字」試試？
這種狀態下，認真打字的話，要小灰常出現應該不是問題！

我電腦最低是 798MHz，通常也都是在這個頻率跑，「預覽列中顯示部份符合的字」原本就勾了，也把字型大小調成跟你的設定一樣，我沒有四碼倉頡，所以用一般倉頡測：

弚→cnl→[1.弚 2.鈏] 
此→ymp→[1.此 2.忐] 
夢→twln→[1.夢 2.甍 3.藅 4.蘮] 
角→nbg→[1.角 2.墮] 
脫→bcru→[1.脫 2.貺 3.鼆] 
源→emhf→[1.源 2.鴻] 
知→okr→[1.知 2.佑] 

還有隨便打一些字，可是到目前為止仍然無法重現。 你的一般倉頡會出現小灰嗎？

感謝coolcd幫忙測試～
上面那幾個例子不一定每次打都能叫出小灰，即使我用四碼倉頡重打那些字我也沒有辦法一定重現小灰。
但是至少確定目前小灰會出現，都和候選字清單頓一下有關。

過去我還是打倉頡的時候，小灰就曾出現過了。

另外，coolcd要不要把「預覽/預選字」打開，並關掉「預覽列中顯示部份符合的字」看看？
我打開「預覽列中顯示部份符合的字」這個功能的時候，反而沒遇見過小灰。怪....

「溝」通，打完「溝」的時候出現小灰，
在四碼倉頡的狀態下，雖然「溝」（拆碼「eetb」）本身不會沒有候選清單，
但是拆碼過程會閃出一次候選字清單（拆碼到「eet」時，會出現 [1.汫 2.洴]）

定「義」，打完「義」的時候出現小灰（四碼倉頡），
義→tghi→[1.義 2.飌]

幾天前到今天，這些小灰的例子都是在leafpad下產生的，
leafpad可以說是這段時間以來出現小灰最多的程式，
但也有可能是因為我很常用leafpad的關係。

在Openoffice.org較少出現，不過倒是造成出字順序的問題↓
gcin在Openoffice.org中的出字順序錯誤
目前這個出字順序的問題我只在Openoffice.org才有遇到，其他程式沒遇過，
或許Openoffice.org的出字機制雖然會使gcin出字顛倒，但是至少可以避免小灰的出現...Orz

今天玩了 kanru 寫的中打遊戲，終於可以重現小灰了，只要執行 ./tw (打字練習的執行檔)，輸入時，如按到 q，會無預警退出遊戲，然後，再次輸入中文時，就可以遇到小灰了。

我在執行 gcin 時加了 GCIN_DBG_TMP=1 GCIN_ERR_CEDUMP=1 ，不過好像沒 debug 到什麼訊息：

gcin get env LC_CTYPE=zh_TW.UTF-8  LC_ALL=(null)  LANG=zh_TW.UTF-8
gcin XIM will use zh_TW.UTF-8 as the default encoding
load_gtab_list /usr/share/gcin/table/gtab.list
-- /tmp/gcin-chia/socket-:0.0-gcin2
connection via TCP is disabled
gtab file /usr/share/gcin/table/ar30.gtab
keybits:6
PHRASE_AUTO_SKIP_ENDKEY
KeyS 41
abcdefghijklmnopqrstuvwxyz./;,1234567890
inmdno: 8 th.KeyS:41
chars 25012
inp->phrnum: 50
key64: 0
----------------- do_ exit ----------------

在執行 gcin 的 console 中，出現：

(gcin:13001): Gtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
(gcin:13001): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(gcin:13001): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(gcin:13001): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(gcin:13001): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(gcin:13001): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed

不過我不確定這是不是我的 window manager 是用 awesome 的關係

 

這個設定，我用了一天多才出現小灰，不能確定是不是如此設定的關係。

懷疑是離開前沒有把 im context detach，剛剛 push 了一個 fix 上去，試試看吧..

BTW, 'q' 是預設的關閉遊戲方法..

那個 message 應該算gcin 的 bug，應該不會造成 error.

今天發現好幾次是沒有出現候選字選單也會出現小灰的！（譬如，「改天」的「天」打完後）
看來候選字清單和小灰之間的關係也不是那麼絕對的，小灰在非候選字清單的狀況下也會出現，
問題又回到了原點...。

雖然沒有候選字清單也出現了小灰，但是全部都是在leafpad下發生的，
或許，...，應該調查一下的是leafpad？
看看大家要不要多用leafpad打字看看？說不定也會遇到我說的情形？
我的意思是，問題可能不在gcin，而是在於某些gtk程式...

我天天都在用 leafpad 耶，沒遇過小灰。

~$ leafpad --version
Leafpad 0.8.15

我前幾天把 gcin 的固定視窗取消掉就沒有發生了。我之前一直是把視窗固定在特定的位置上的。

參考看看 :)

國外疑似小灰的討論....
有人認為是gtk造成，也有人建議降級gtk來解決

http://bbs.archlinux.org/viewtopic.php?id=31355

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464462#22

https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/159778

http://ubuntuforums.org/showthread.php?t=814420

http://ubuntuforums.org/showthread.php?t=820974g

詞音難得出現小灰，拍照留念∼

 

我是發現當我打太快的時候就很容易發生

不管是詞音或是注音

我通常是預設注音輸入法

一分鐘我大概可以打6x個中文字

如果用我感覺上一分鐘超過30個字的速度，就很常發生選字框爛掉的情況

詞音會好一點，但是也是會發生(另外因為我打熟了，大部分我連選第幾個字都是手指自動反應，所以詞音我用不太慣)

 

哇，高手。

目前看起來問題出在 GTK 上，偏偏我已經很久沒看到小灰的問題了。

等最近有空，在選單上加個重新 create window 的選項好了。

期待中，有個create window就很好了

不然我每次連aMSN都得一起重開

跟人家聊天聊到一半要叫人家等我，好累

 

話說... 自從換了平台重新安裝系統後，就沒再遇見小灰了。小灰的成因會不會其實是出現在 gtk 逐步升級的這個動作上？

有可能。因為我發生小灰後（通常 gtk 等都曾升級後），
就會把 gcin 重編譯一遍，好像就不會發生了。

不過，不排除 X 相關 lib 也沒有同時重編譯的關係，這在
linux 平台較少見，但在 bsd 平台有時會發生這種地雷。

其他環境不清楚，但 gentoo 下原本就會因為安裝新版 gcin 而將 gcin 編譯過，但小灰還是會發生。 第一次察覺不到小灰是在 nb 上的 gcin 竟然沒遇過小灰，然後 10/5 換過平台全新安裝系統後也不曾再見過小灰，才讓我懷疑問題不一定出在新版 gtk ，反而可能是整個 gtk 更新的動作上....

再想下去，之前最常發生小灰的情形通常發生在系統繁忙的情形下，有陣子是懷疑是不是 amd 平台的 cpu 多緒控制效能不如 intel 的關係，但總不會所有發生小灰問題的人都使用 amd 平台吧？

我長年來都是用 AMD CPU，沒遇過小灰。

最後一次用 Intel x86 / x86-64 是 Pentium 166 那個年代。

 

我的是intel pentium M (centrino)，小灰一樣會出現，
另外一台Transmeta Crouse 5600的CPU，超慢！只要用彈出式視窗就會常常出現小現小灰！

好像打錯也容易變成亂亂的

目前能夠確定的大概只有小灰的形成環境總是和系統效能不彰有嚴重關連...

來段新影片，如果順利的話，這段影片會找機會回報給gtk～
註：ogv格式，我不確定是不是所有播放器都能開，至少試過mplayer可以

最好提到其他的程式也有 bug，否則可能會被認為是 gcin 的，且gcin 他們又用不到。

最好回報在 gimp 的問題，他們可以自己去找慢的 cpu 測試。除非 GTK 的人可以自己試出相同的問題，否則很容易被忽略。

最好可以試出那一個版本的 GTK 改變造成這個問題，當然愈精確愈好，意思是最小的版本改變。這樣他們就可以根據兩個版本的 diff 找出那一段 code 改壞掉。

目前正在草擬一段回報給gtk團隊，但是小弟英文很差，所以希望路過的朋友們幫忙看看是否難懂或錯誤，
感謝大家～

http://sites.google.com/site/winlin0330/