在 2012年5月24日 星期四 01:24:41,Ma Xiaojun 写道:
I'd like to point out a theoretical advantage of ibus here. Please correct me!
ibus's IM engines are run in separate process. This is irrelevant to users if engines and the framework are maintained by same group of people.
However, if we are going to add Win32 IM support to wine one day. Then multi-process architecture can make things much easier.
Best Regards, Ma Xiaojun
If you want to discussion on this point, I will never agree on this, technically. This is one of the most important reason that fcitx can work like this while ibus not. Gcin filter is kinds of similar idea but fcitx push it to a higher level. You cannot imagine things like this in ibus (or any other IMF): table simply use pinyin's code to process temporarily pinyin mode. And if you know mozc, you will know it have a mozc server itself. So there is no limitation for an input method engine to use a separate process if it want to, while ibus only force this. If the engine author want, he can just do it in any other IMF. Multiprocess and single process is not a good question for IMF is good or not, though it's irrevanlant, do you know the similar quarrel about postgresql and mysql architecture (single process and multiple process)? I admit mulitple process have some advantage, but force engine to be multiple process will bring too much unneeded limitation (at least for me). I once planned to add an easy interface for multi-process in fcitx, though the plan postponed since I don't think it's important for now. P.S. Some irrelavant complain, you and Su take about some technical point (no matter on ibus or fcitx) while don't know WHY developer choose it, you guys may just do "ah I see it", and talk about it.