今天在手提電腦那邊試，組字視窗變成了這樣子~

  然後我在desktop再試(灌了nvidia原裝driver，應該不是顯示問題)

 試了一會，發覺要是打得超快的話就會變成上面那樣子....

那種小灰的情形在某個版本的 GTK 有遇過，我有去 debug 過，發現 gcin 有送 string 給 GTK，但 GTK 就是不顯示。理論上除非有嚴重的 bug，gcin 是不可能把 window 搞成這樣。gcin 都有 valgrind 測試 memory 過。

另外一個可能是 update Xorg 後沒有重新 install nvidia driver，在某些情況可能會造成一些錯誤。X server 是採取 static link .a driver 的方式。

我主要是筆電有這個問題~

我筆電是用Radeon IGP顯卡，當初我是以為是ATI卡驅動有點缺陷的問題吧~

因為桌電一直用著其實也沒有這問題， 只是發覺筆電偶然有這問題(但登出再登入後便沒事)

我便試著在桌電不斷按掣的打字，發覺快速的去閃選字視窗是會那樣子~

我今晚會檢查一下顯卡的驅動，謝~

個人很喜歡gcin的介面，所以也一定會繼續用的~ :D 

同意Samuelic所說的

我在舊電腦上也發現「打得超快」時，出現的機率極高，幾乎每次都會！
出現小灰好像都是剛好在使用彈出式視窗的情形
我換成 非彈出式視窗看看好了

測試結果發現，使用彈出式視窗時，在qt程式下的發生率最高，譬如：skype、kword
gtk程式則相對較少出現這樣的問題
在qt程式下最容易出現小灰的情形是，快速打字，快到讓gcin的彈出式視窗跟不上去update內容的時候！
以現今一般電腦的等級，發生機率頗低，但在我的舊電腦上，打字當當會出現lag，相當容易就讓小灰重現！

不過，為什麼小灰會在qt程式上較容易出現，我就不明白了

剛剛又作了新的嘗試！
我發現在使用xim的狀況下才比較會發生這種情形
我的skype、kword都是用xim，我剛剛試了沒有經過patch的rxvt（也是使用xim的）
rxvt同樣打沒幾個字就出現小灰了！(彈出式視窗)
然而那些使用gtk-immodule的程式，如leafpad、epiphany，再怎麼操gcin的彈出式視窗，小灰都不會出現

或許，有些問題和xim有關？ 

我用 rxvt-unicode (XIM)  加上開了兩個 neverball ，以降低 celeron 1.3G cpu 的速度，還是試不出來。 

老大～ 要讓CPU慢到gcin打字偶爾都有點lag，這樣會比較容易出現啦 還有，建議不要用詞音輸入法來試（因為它的組字視窗不太會彈） 建議找gtab輸入法＋彈出式視窗，要打得超快而且要有輸字才行，這樣gcin視窗才會狂跳到發白，然後升級成為小灰 ps. 我待會看能不能想辦法錄一段flash丟上來 by winlin

不負小灰所託，小弟把錄影檔放上來了(如附件)

抱歉，不太會拍，所以，gcin在下方被切掉一部份
反正看得懂就好，打到後來，gcin變成小灰就是了  :)

我桌電E8400+8800GT，用gedit也能弄到小灰出來~

不過正常使用出現小灰機會真的很少! 

但慢電腦下出現的機會便大很多，曾經試過在筆電(P4 1.8+IGP 320M)只打了4個字便出現了，不過也偶發的~

Samuelic好～
如果您有空的話，請問您能否幫忙確定一下，您使用gedit時，gcin是否正使用xim？

有個簡便的方法可以確定：

gcin-setup > 內定輸入法 開啟 & 關閉 > 直接進入中文輸入狀態（限非XIM） → 把這個打勾

之後，開啟應用程式 ，若gcin在不需ctrl+space的狀態下直接進入中文輸入狀態，則表示gcin不是使用xim，反之則是xim

當然，沒空測也沒關係啦

謝謝您～ :)

最近出現的頻率真是頻繁...，連打leafpad都會這樣（非XIM）。

發現一個有意思的現象，
如果是打倉頡時掛掉，切換到其他gtab輸入法時仍是小灰（如大易、嘸蝦米、倉五...等），
但若切到注音、詞音、內碼時，則是正常的。

不妙...雖然這個問題不是出在gcin，但是太常出現的話，多少會影響一般使用者用gcin的意願，
找出bug還是必要的，
有人知道如何確定問題是出現在gtk、cairo、fontconfig或freetype何者的嗎？

謝謝～ 

降級回到下列三個套件之後，小灰就沒再出現過了！ 

Get:1 http://debian.nctu.edu.tw stable/main libgtk2.0-bin 2.8.20-7 [7168B]

Get:2 http://debian.nctu.edu.tw stable/main libgtk2.0-common 2.8.20-7 [3755kB]

Get:3 http://debian.nctu.edu.tw stable/main libgtk2.0-0 2.8.20-7 [1620kB]

 或許真的是gtk的嫌疑最大...請問應該如何向gtk團隊回報問題呢？

 

註：降級版本號相關訊息如下： 

dpkg - warning: downgrading libgtk2.0-bin from 2.12.9-2 to 2.8.20-7.
dpkg - warning: downgrading libgtk2.0-common from 2.12.9-2 to 2.8.20-7.
dpkg - warning: downgrading libgtk2.0-0 from 2.12.9-2 to 2.8.20-7.

有關閉 X11 composite 嗎？

我的/etc/X11/xorg.conf裡沒有設這個...

xdpyinfo | grep Composite，沒看到任何東西，應該是沒開.... 

caleb兄，小的是用lenny，為了搞清楚究竟是哪個套件出問題才把特定套件降級為etch的套件

由apt-cache show gcin可以發現gcin相依的套件如下：
 Depends: libatk1.0-0 (>= 1.20.0), libc6 (>= 2.7-1), libcairo2 (>= 1.4.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.20.2), libx11-6, libxtst6, gtk2.0-binver-2.10.0

我當時的想法是，這幾個套件一個個試，或許就可以抓到問題來源。
我本來是想先試libcairo2、libpango的，不過出了一點狀況，所以我就改先降級libgtk2.0-0試試。
降級後，因為相依性的問題，gcin-1.4.0-pre11也被迫移除，
我只好先裝上了etch的gcin（好像是1.3.0），但是發現xim不能用，
後來改用caleb兄編的 1.3.9-1~tan1~bpo40+1（deb http://www.calno.com etch-backports main）。

我知道，因為gcin也降級了，所以仍不能排除gcin-1.4.0-pre11和小灰之間的關聯性。
不過，如前所述，小灰的問題是在1.3.5時就不定時出現了，照理說，如果和gcin有關的話，
1.3.9的版本應該也要出現小灰才對，但後來小灰就沒再出現了。
因此，就推論上，我個還是比較傾向和gtk套件有關，而不是gcin。

如果caleb兄願意進一步排除是不是gcin-1.4.0-pre11造成的，或許可以考慮編一個1.4.0-pre11的etch backport，
小弟可以再試試～感謝您～辛苦了～

麻煩回報 cpu，看是否是在速度較慢的 cpu 容易出現

我有三台電腦都出現過小灰
Transmeta 5600 → 超頻繁出現，用xim機率最高
Athlon XP 1700+
Intel(R) Pentium(R) M processor 1.73GHz

可以麻煩 compille gcin 然後用 valgrind 執行看看

 

cd gcin-1.4.x

./configure

make

./tval                               用 valgrind 執行，會跑出一個 gedit 的 window，然後在裡面輸入看看，儘量試到出現小灰的情形。

 

必須先 install valgrind。 valgrind執行速度很慢，第一次啟動 gtab，請耐心等個 10-30 分鐘。

注意看 terminal valgrind 有沒有 report  error message， 

然後在此回報

 

Thanks.

晚回了...

我找不到直接進入中文輸入狀態這選項....

但我一向也是需ctrl+space的狀態接進入中文輸入狀態~

應該有使用xim吧@@

呃...萬萬沒想到....那位小灰兄連在非彈出式視窗的時候也可以出現！！！
正當我在opera上打字，又順手以快速鍵開個xterm的時候，快速切回opera才打幾個字，小灰就出現了！
而且我還是在用「非彈出式視窗」的時候

這下可好了，小灰變成一塊白色的形狀，組字時會才會出現右側那塊小小的灰色

 

報告，在下也碰到了。

archlinux  & gcin-1.3.9 & KDE-3.5.9。

 

 

 

10:47 LGJ 我發現，小灰並不是 gcin 的專利。icewm 本身就有這種情況。
10:47 LGJ
10:48 LGJ 黑成一片。所以，應該可以肯定，小灰的造成原因並不是 gcin 本身的問題。
10:49 winlin 我之前在gcin未出現問題之前，gimp就先出了狀況
10:50 LGJ
10:50 LGJ ↑這才是正常的。
10:51 winlin 當時我在做gcin icon的時候經常要在gimp裡頻繁且快速地另存新檔，就曾經好幾次出現那樣的問題
10:52 winlin 一開始我以為是gimp的問題，但降級之後還是一樣，我才懷疑和gtk有關
10:53 LGJ 對，一般就是『頻繁且快速』的情況出現的。
10:53 winlin 沒錯！

所以，我們好像是找錯方向了。
 

不知道是誰的問題，icewm 也有用到 gtk 的一部份

 ldd `which icewm`
    linux-gate.so.1 =>  (0xffffe000)
    libgdk_pixbuf_xlib-2.0.so.0 => /usr/lib/libgdk_pixbuf_xlib-2.0.so.0 (0xb7f9a000)
    libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7f80000)
    libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7f40000)
    libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7f3c000)
    libdl.so.2 => /lib/libdl.so.2 (0xb7f38000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7e7d000)
    libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7e79000)
    libSM.so.6 => /usr/lib/libSM.so.6 (0xb7e70000)
    libICE.so.6 => /usr/lib/libICE.so.6 (0xb7e57000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0xb7d59000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7d52000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7d49000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0xb7d38000)
    libXft.so.2 => /usr/lib/libXft.so.2 (0xb7d24000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7ca9000)
    libz.so.1 => /lib/libz.so.1 (0xb7c96000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7c68000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7b7a000)
    libm.so.6 => /lib/i686/libm.so.6 (0xb7b54000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b48000)
    libc.so.6 => /lib/i686/libc.so.6 (0xb7a04000)
    /lib/ld-linux.so.2 (0xb7fc5000)
    libpcre.so.0 => /lib/libpcre.so.0 (0xb79dc000)
    libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb79da000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb79bc000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0xb79b9000)
    libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7883000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb787d000)

哎呀，新發現！！！
我發現把gcin擠在畫面最下緣時很容易出現小灰！！！
難怪最近在ptt上推文時，小灰一直出現！！！因為推文的時候，gcin就在最下面呀！
目前測試結果，PCManX、lilyterm、leafpad都會因為把gcin擠在畫面下緣而出現小灰
（leafpad把gcin擠在畫面下緣後，要打久一點才會出現小灰）

 

我一直都會有這樣的情形，不過偶爾才發生

最近用nxserver發現，在網路不順時，很容易就跑出小灰來

狀況:

按下第一個鍵時，gcin會在滑鼠指標上畫出一塊小灰

這時如果稍等一下，會看到小灰移到游標的地方，然後正常的字就出現了

要是在小灰還沒消失前，很快的按下空白選字，有很大的機會小灰就誕生了

切換到另一種輸入法後就恢復正常，但一換回原本的輸入法又跑出來

希望這樣的描述能看得懂

用了固定gcin視窗的模定還是不能太操電腦，否則小灰還是會出現...
我這次是一邊打字一邊開個opera， 小灰就又出現了...

 

 

問了一位朋友，他說之前他用32位元的系統時也是經常出現，換成了64位元的系統之後就沒再出現過了，

不知道32位元和64位元的gcin差在哪裡？ 

「固定視窗 + 非彈出式視窗」 出現小灰的情形今天再添一例，

這次是在Gnome+compiz的狀況下，補張圖作個紀念