[問題]gtk 2.0的軟體能開啟over the spot 的模式嗎

[阿威]

我的軟體只要是gtk2.0的都只能開啟ROOT模式，請問可以使用over the spot的模式嗎???

[阿威]

這裡找到一些資料。

GtkIMContextXIM does not support either over-the-spot or off-the-spot.
It cannot, because these
styles will require a XFontSet, but gtk+2.0 does not use the XFontSet.

For gtk-im-preedit-style and gtk-im-status-style, "callback" for
on-the-spot and "nothing" for root-window-style are valid values, and
they should be effective at run-time by changing with
gconftool-2.

好像是只支援onthespot的樣子，不知道了解的大大清不清楚這個情形。

另外xcin支援了onthespot了嗎???

[阿威]

再轉貼


: 我有些兒懷疑，照 Owen 的說法將來 gtk+
: 新的 IM framework 將不再支援 OverTheSpot style.
: 而且他希望 XIM server 都能改支援 OnTheSpot.
: 這是為什麼呢?
: 印象中 OverTheSpot 才是適合中文的 style,
: 而 OnTheSpot 比較適合韓文。
: 為什麼 Owen 說要 IM developers 放棄 OverTheSpot?
: 還是我對 OnTheSpot 的理解有誤?
:
: 對 OverTheSpot / OnTheSpot 的說明可參考這裡
: http://www.mizi.com/kde/doc/onthespot/onthespot.html
: 上面還有個動畫示範兩種輸入法的不同。
: 由此可看出 OnTheSpot 是適合韓文的 style
: (但不適於中文)
:
: 東瀚你的看法呢?
^^ 翰

我的看法啊 ....

1. 我們又有苦工要做了 )

2. 我們這邊沒有有力的人士過去跟他們吵: OverTheSpot 才是最適合台灣地區
中文輸入的模式。

3. 亂猜 .... gtk 他們可能想掌控一些東東。所有的輸入模式中，只有 OnTheSpot
是將輸入法資訊交由 XIM client 來畫的，其他所有的模式，都是 XIM server
來畫。在 OnTheSpot 中，XIM server 無法插手繪圖的工作，它只能提供一些
資訊，建議 client 該怎麼畫，要畫些什麼。然而，最後的決定權是在 client。

就程式實作上的難易度來看:

OffTheSpot > OnTheSpot > OverTheSpot > Root

不論是在 XIM server 或 client 那邊都一樣。OverTheSpot 只比 Root 多一道手
續而已，就是將 client 目前 spot location 傳給 server。而其他兩個就複雜很
多了，因為那兩個的繪圖位置都在 client 視窗，只是前者是 server 來畫，後者
是 client 來畫。這時後不論 server 或 client 都要小心處理 callback 函式。
而且，在文字輸入過程中，前二者所耗的系統資源會比較多一點。

就 XIM server 的立場來看，不論使用者會不會用到，理論上我們都要支援這幾種
模式，這樣才能算是一個完整的 XIM server。因此，OnTheSpot 我們一定會做，
只是對台灣這邊的使用者而言比較不會用到，故它的優先性就不是那麼高了。

(ps：這個是11 Dec 2000 的文章，不知道現在如何了，xcin.linux.org.tw掛了，不知道要到哪裡找資料說)

[阿威]

Chinput 似乎四種輸入模式都支援了說
ROOT overthespot onthespot offthespot

[阿威]

這個連結有四種輸入法的範例，大家可以看看。

http://www.mozilla.org/projects/intl/in ... -spec.html

[阿威]

The current developement of xcin is the migratioin from XIM to iiimf.
So, on-the-spot will not be there in the near further!

這個大約是今年一月的gnome mail-list，因此最近的xcin應該是不會有on-the-spot的支援的。

[阿威]

再轉貼一個有關iiimf的訊息，給有興趣的人參考。

網址如下

http://list.softwareliberty.org/piperma ... 02084.html

Hello, 各位好 )

ICOS02, Li18nux Taiwan adhoc meeting 總算在「兵慌馬亂」中開完
了，可以喘一口氣了 )

在此，我謹代表 xcin 開發計畫向大家宣佈一個好消息: 我們將加入
Li18nux 旗下 Input Method --- IIIMF subgroup，並且讓 xcin 朝
未來更完善的輸入法架構 IIIMF (Internet/Intrnet Input Method
Framework) 前進。 Li18nux 的主席，同時也是目前大家所用的 XIM
協定作者、 gettext 概念的原創者、以及 IIIMF 的設計者 ----

Hideki Hiura

對此感到非常興奮，他說他非常歡迎我們的加入，一起與 Li18nux
的開發團隊合作努力 )

幾分鐘前我已見到 informer 兄在 xcin mailing list 上 post 一封
簡述 xcin 如何整合到 IIIMF 架構的文章了，在此謝謝 informer 兄。
簡單來說， IIIMF 的架構中系統裡只會有一個輸入法的 server, 它的
角色就像 sendmail 一類的 daemon 一樣，在系統剛開機時就啟動，關
機時才結束。它 "本身" 不提供任何輸入法，也不提供任何使用者介面。
這些輸入法與使用者介面都是以動態模組的方式外掛上來的。因為該
server 與使用者介面完全無關，因此它可以同時用於多種平台，如

1. X Window
2. Console 文字模式
3. Java
4. ....

同時，它也完全跳脫現有的 XIM 架構限制，支援它的應用程式可以在
run-time 直接切換輸入的語系，而不需重新設定 locale, 再重新啟動
程式 .... 等。再者，我們將設計輸出入重導向，如此它將能與語言輸
入、手寫板輸入等程式溝通，達到這些特殊輸入的要求，而這也將可達
到如 console 模式下使用 jmcce 而直接操作 xcin 輸入法模組，或在
X Window 中使用 xcin 輸入法視窗直接操控 jmcce 的輸入法模組這類
的特殊工作 (前提是，假如 xcin 與 jmcce 都走向 IIIMF)。更重要的
是，它將完全擺脫 XIM 的限制與缺陷，以往常見的 KDE logout 或 kill
xcin 導至整個 desktop 當掉的情形將不再發生了，而且，原本已支援
XIM 協定的應用程式也不需再修改，依然可以接受來自 IIIMF 的輸入法
server 的文字輸入。

其他有關 IIIMF 的詳細資訊，請見 Li18nux 的網頁:

http://www.li18nux.org/subgroups/im/IIIMF/index.html

(您會見到，該網頁的 Language Engine 表單中， xcin 已經列進去了 )

對於 xcin 而言，走向 IIIMF 會很難嗎？技術上其實不難，我們要做
的只要將原本的 xcin 做適當切割，實作出符合 IIIMF 標準的 xcin
GUI 模組，以及 xcin 輸入法模組，就可以自然地整合上去。而我個人
的理想是，希望在同一份 xcin 的 source code 中，使用不同的 configure
option 就能自動 build 一份 for IIIMF 的模組，或者 build 一份原
本使用 XIM 協定的 xcin XIM server, 以和目前的實作相容。

以上是我們的中文輸入問題 (事實上，是世界各國的輸入問題) 的一個
美好的遠景，但要達到這樣的遠景，需要大家共同努力才能實現。目前，
我們已開始研讀 IIIMF 的相關文件 (可於上述 IIIMF 的網頁中找到)，
並且要對它進行一些測試，要在有充份的了解與掌握它之後，才能開始
進行 xcin 方面的整合工作。

在此，我們歡迎任何有興趣的朋友與我們討論，加入我們的開發行列 ))


Best Regards,

T.H.Hsieh

[swallowman]

阿威兄:
看了一下您的資訊,有幾個問題想請問一下.
1.是不是以後IIIMF就直接崁入xfree86呢(以xfree86來說)?那text mode呢?
2.那現在的gtk2的軟體有甚麼折衷的方案來輸入中文?或是不要用gtk2的軟體呢?
3.有testing的角色可當嗎~?

[阿威]

1.之前xcin的網站都掛了，所以沒法給你正確的資訊，今天我在去xcin的mail-list去找資料，似乎也沒有啥IIIMF的訊息說。
2.gtk2.0還是可以用xcin進行輸入，只是不能over-the-spot的方式輸入而已(只能用ROOT的方式)。
3.我去xcin的網站上看了很久了(老實說最新的news也是2001年的)，似乎也找不到新的訊息，我猜想，xcin是緩慢(可能非常緩慢)的進行它的IIIMF計劃。

[阿威]

再轉貼
http://list.softwareliberty.org/piperma ... 02112.html
>
> 在此我很高興向大家宣布，我們 xcin 計畫有新的 cvs commitor 囉 )
>
> Kuang-che Wu <kcwu@ck.tp.edu.tw>
> Pofeng Lee <informer@m2000.idv.tw>
>
> 由於這兩位朋友長期以來對 xcin 計畫的貢獻，因此我特地邀請他們一同
> 維護 xcin cvs repository。感謝他們的頂立相助 ) 以後如果有 xcin
> 相關的 patch, 您可以寄到本 mailing list, 或者我們三位，我們在看過
> 沒有問題後，就可以 commit 了 )
>
> 雖然我們將開始往 IIIMF 前進，但現有的 xcin-2.5 系列還是要繼續維護
> 下去。之前我收到過許許多多網友的建議與 patch, 但由於當時課業太過
> 繁重，故很抱歉我潛水了很長一段時間，而沒有任何回應。現在我總算可
> 以喘一口氣了，因此未來一個禮拜內我們將陸續處理大家先前給我們的 patch,
> 並準備 xcin-2.5.3 的 release )
>
> 另外附帶一提，未來往 IIIMF 前進的 xcin source tree。我現在還無法預
> 期到時原本的 xcin source 會有多大幅度的更動，故為了方便起見，在往
> IIIMF 方向發展的 xcin 版本，我會考慮另外弄一個 cvs source tree:
> xcin-iiimf, 以與原本的 xcin 做區隔，等到 xcin-iiimf 的部分到達一定
> 的完成度後，再 merge 回原來的 xcin source tree。這只是一個構想，不
> 確定是最好的做法，所以想聽聽大家的意見 )
>
> T.H.Hsieh

[swallowman]

> 另外附帶一提，未來往 IIIMF 前進的 xcin source tree。我現在還無法預
> 期到時原本的 xcin source 會有多大幅度的更動，故為了方便起見，在往
> IIIMF 方向發展的 xcin 版本，我會考慮另外弄一個 cvs source tree:
> xcin-iiimf, 以與原本的 xcin 做區隔，等到 xcin-iiimf 的部分到達一定
> 的完成度後，再 merge 回原來的 xcin source tree。這只是一個構想，不
> 確定是最好的做法，所以想聽聽大家的意見 )
>
> T.H.Hsieh

great,more ppl ,more power,i like cvs port,it's nice for tester.
但我支持也沒用,不知有沒有人想加入測試行列.debian環境還不是很熟,但我也可在gentoo上作ports供使用,sorry,我應該要多花點時間熟悉debian的環境><.