--- On Mon, 26/3/12, Aric Stewart <a...@codeweavers.com> wrote: > Hi, > > Not to argue if it will be useful or not, as I do not know. > I think this > will be technically very hard. You will have to be able to > get the > keystrokes for a native linux applications feed them into > WINE, have > wine do the IME processing and then get the resulting > characters and > feed them back into the native linux application. This > pipeline is not > trivial.
Getting arbitrary microsoft or 3rd-party input methods to work with Wine (for windows application under wine) would be an interesting project. Getting arbitrary microsoft or 3rd-party windows input methods to be useable by native [unix] applications would be less useful - and as you wrote, rather troublesome for the sake of it. I would have to say, the perceived problem with ibus/fcitx/whatever's pinyin implementation is simply failing to naming the issue correctly: it is not that the pinyin implementation on Linux/X11 is poor, but that an entire generic input mechanism (which applies to both pronounciation/pinyin-based methods, as well as shape-decomposition-based methoids like Cangjie) that of predictive/anticipatory/auto-completion, is missing. If you cannot name and describe the issue correctly, you are simply "barking up the wrong tree", as the saying goes. Also, it is not true that such feature is entirely missing. The Japanese had done some very interesting work in anticipatory XIM inputs based on dictionaries (the typical linux installation actually ships several, from time to time), and I believe that the Taiwan people had done similar as well (these are available more under niche localized linux distributions); one problem is that those technical development has so far largely stayed localized - native-speaking linux/X11 people know where to find them, but have very little incentive or patience of pushing those technical developments back and integrating them into the western/English-speaking world. > Additionally, you have not explained how this will benefit > WINE. I can > forsee none of the above pipeline being accepted into or > applicable to > WINE presently, at lest in theory, i have done work that > allows native > XIM clients to be able to work in wines IME framework, so if > a user > really wants to use windows XIM in wine they should work. > The setup is > tricky but in all my years of working on wine IME i have > never heard of > a user wanting that. Almost all requests are to make > the Linux/Mac > Input Methods work better in WINE. > > I would love to have you work on improving IME and XIM > integration in > WINE, but i think the main goal of the project is pretty > tangential to wine. Yes, I agree "make the Linux/Mac Input Methods work better in WINE", or just "make the Linux/Mac Input Methods work better" are desired. Actually an ibus<->google-chinese bridge would be interesting, but that's completely othorgonal and unrelated to wine. (except in the sense that wine itself is one X11 application among many).
