Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

Tag Archives: ibus

ibus-chewing-1.4.4 released

  • Resolves Bug 842856 – ibus-chewing 1.4.3-1 not built with $RPM_OPT_FLAGS
  • Resolves Bug 1027030 – CVE-2013-4509 ibus-chewing: ibus: visible password entry flaw [fedora-all] Thanks czchen for the GitHub pull request 39.
  • Added translations: fr_FR, ja_JP, ko_KR 
  • Adopt cmake-fedora-1.2.0

ibus-chewing-1.4.3 Released

本次修正:

加入了 buganini 所提供的兩個修正:

1. https://github.com/definite/ibus-chewing/pull/31

2. https://github.com/definite/ibus-chewing/pull/30

感謝 buganini 的辛勞。

 

ibus-chewing-1.4.2 released

ibus-chewing-1.4.2 已經釋出,可在  https://code.google.com/p/ibus/downloads/detail?name=ibus-chewing-1.4.2-Source.tar.gz 下載。

本版改進之處:

  • 被選擇的字串不會在切換輸入法時被截去。
  • Shift 不會再送重複的字串
  • CMAKE_INSTALL_PREFIX 不會被鎖定為 /usr
  • 若在非Fedora 運行,ibus-engine-chewing 會被裝在 /usr/lib[64] 以符合 FHS

感謝 Buganini 的辛勞,多次提供修改意見。

ibus-table-chinese released!

As title,
已將版權有疑義的表拔除 (i.e. 鄭碼與自然碼)

此外就是把原先的 ibus-table-wubi更名為 ibus-table-chinese-wubi-jidian,(極點五筆),因為那個表應該是極點五筆的表)。
並增加 海峰五筆 (ibus-table-chinese-wubi-haifeng)、行列30以及行列30大字集。

感謝 海峰兄將海峰五筆以 BSD 發行,
dgod 兄將永碼以GPLv3發行。

重新檢視IBus-table 中文輸入法版權

前一陣子接手ibus-table以及所有的ibus-table 的中文輸入法。
看到即使是財大氣粗的Microsoft 都在一審對中易敗下陣來,想說那就對這些中文輸入碼表好好作一番檢視吧。
成品(?)在此

Tom Callaway

Does Opera 10.60 supports IBus?

I’ve been waiting the opera release version for IBus support. And finally Opera changelog states that it support IBus and scim. I then download the x86_64 version for my desktop which runs Fedora 12.

But, WTH, ctrl-space still not trigger the input method?Great. I’ve tried various environment variables, but still no use.

Then I use okteta to dig the opera binary, and find the string.

XOpenIM

Ok, it uses XIM. (Guys and gals, no need to play with GTK_IM_MODULES and QT_IM_MODULES, they don’t work).
IBus does support XIM, but my IBus icon still unlit with opera (My language bar is always on).

Finally, I thought this might only appear in 64 bit opera, so I install the 32 bit opera in my mini311 which runs Fedora 13, and it worked out-of-box (sort of). So I went back to my desktop and install 32 bit opera, and it worked.

When I was searching the solution of using IBus with opera, I noticed that many ibus-pinyin user complained that ibus-pinyin cannot send the whole sentence to opera. My ibus-chewing has this problem as well, but you can avoid this issue by setting the option input style to “in application window”.

Inputting CJK in Opera 10.5x

I have been  loyal to opera since opear 6. It was a major innovator. For example, multiple tab browsing, mouse gesture, and speed dial was their invention.

However, for us, CJK linuxer, riding with opera was and is bumpy. While with other browsers you can just install and play, you have to manually set a environment to make it works, or use Google to dig out "forbidden" qt4 or static build.

Now came to the era of 10.5x, great, there is no known way to enable input methods. No ibus, QT_IM_MODULE, xim, not at all.

Finally, when I reach the opera forum, their answer is something like, "No, not yet, please wait until we are ready for final." Well, just hope I don’t have to wait too long.

opera qt4 and ibus

Once upon a time, opera does not get along with ibus well by default. Normally, your have to set
QT_IM_MODULE=xim
in order to make the input work.

However, that workaround still come with problem: Whenever you restart ibus, opera will go down with it, though it will manage to crawl back, but what you type is lost forever.

Given ibus provide qt4 interface, I went to find opera qt4 build.
I’ve tried opera 1010 beta qt4 static build, it turned out working well.
But not shared build, according to Peng Huang, it crashed with ibus-qt4.

There is a thread about the differences between qt3 and qt4 at here
, which says that the main difference is merely the skins. That’s incorrect. At least it provides some remedy for input method users.

On IBus Xkb intergration (3)

Yesterday Caius Chance, Jens Petersen and me discussed my approach.
Petersen raised an interesting question:

What if a user want to learn, say Zhuyin input method, on a French AZERTY keyboard by seeing the software keyboard layout?

Mmm, I did not think of that, though Zhuyin can still work on AZERTY keyboard by changing the layout to us-QWERTY. Nevertheless, it is always nice to have visualized software keyboard.

This let me back to further consider Hutterer’s approach.

Number pad on telephone and computers are a good analog for westerners to understand why CJK input methods are in current shapes. Number pads on phones look like:

1       2(abc)  3(def)
4(ghi)  5(jkl)  5(mno)
7(pqrs) 8(tuv)  9(wxyz)
*       0       #

While number pad on computer keyboards look like:

7(home)  8(↑)    9(PgUp)
4(←)     5       6(→)
1(End)   2(↓)    3(PgDn)
0(Ins)           .(Del)    

If what you need is number, you only need to switch layout among phone, computer, or system default. However, you need hack (i.e. input methods) to input English on top of them.

There are at least following setting combination to type English on number pad:

  1. IM: T9, Layout: Phone
  2. IM: T9, Layout: Computer
  3. IM: T9, Layout: System default
  4. IM: MultiTap, Layout: Phone
  5. IM: MultiTap, Layout: Computer
  6. IM: MultiTap, Layout: System default

Where

  • Layout phone: 3(def) key is always on top right, regardless the mark on the number pad.
  • Layout computer: 3(def) key is always on bottom right, regardless the mark on the number pad.
  • Layout system default: Location of 3(def) key depends the mark on the number pad.

Peter Hutterer mentioned in the case of mobile phone, symbol ‘3’ is bind to top right key, while we still need to interpret what symbol ‘3’ really means (should it be ‘d’, ‘e’, ‘f’ or just ‘3’) in input method level.

Thus, the question can be reformed as:

Where should we interpret “d e f” to 3?

Currently, I think this can be done in “im-variant” level.
But in this way, software keyboard visualizer need to aware of this, then it is able to show the sensible key layout.

On ibus-xkb intergration (2)

Today I re-read Hutterer’s blog, I find out he also suggested that language toggle can be done by switching keyboard layout. Unfortunately, input methdos are far more complex than that because of following reasons:

Input methods that don’t really bind to a keyboard layout

Namely, pinyin/phonetic based input methods. Pinyin just combines English alphabets to Chinese characters, no matter on QWERTY, DVORAK, or COLEMAK. A dvorak user expects dvorak “pinyin-layout”. But what should be shown in language bar?

Indeed, Peng Huang can copy-paste en-QWERTY and en-DVORAK to make zh-QWERTY-pinyin and zh-DVORAK-pinyin, but COLEMAK, QWERTZ, AZERTY users won’t be supported until Huang explicitly copies those layouts. Doesn’t that make layout package bloated?

Input methods that share keyboard layout

Some input methods share keyboard layout. For example Cangjie 3, Cangjie 5, Quick 3, Quick 5 all use Cangjie layout. What input method should zh-Cangjie mapped to?

One key, multiple symbols

It’s not uncommon multiple symbols are mapped to one key.
If I take it correctly, the keyboard layout is essentially key position -> keysym.

But think about input metod and keyboard layout on a mobile phone keypad. What symbol should the top right key map to? Normally it should be 3.
But you still need an IM to interpret “33”, which might be either “de” with T9,
or “e” with “standard abc”.

Perhaps, that’s why MS Window use the term “keylayout/input method” for their input support. 🙂

Back to ibus-xkb intergration.
Here I don’t want to discuss the technically details but UI.

There would be a list of language – input method – keyboard layout (or xkb setting) combination. Like:

en,,,us,
en,,,us,dvorak,
en,,,us,dvorak-classic,
en,,,gb,
en,t9,,keypad,
en,morse-code,,straight-key,
jp,anthy,,us,
jp,anthy,,jp,
jp,anthy,,jp,kana
zh,pinyin,,*,
zh,cangjie3,,us,
zh,cangjie5,,us,
zh,chewing,,us,
zh,chewing,et,us,
zh,chewing,hsu,us,

1st field is language.
2nd is input method (can be null if don’t need it ).
3rd is input method variant, like the custom Zhuyin layout (can be null if don’t need it ).
4th is keyboard layout (in xkb sense). ‘*’ is for following the system default layout.
5th is variant (in xkb sense).

The benefit of choosing these combinations are

  • Can invoke input method support on-the-fly. Invoke the IM module if you need one, deactive or free the IM module if you don’t need it.
  • Compatiable to both IBus and xkb.
  • IBus know which layout is needed for the IM.
  • Also support keypad and morse code input. 🙂

Although I prefer to let IBus handles the language combination switching,
I would like to know the better approach.