On Thu, May 24, 2012 at 11:45 AM, Weng Xuetian
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. I guess I noted gcin's filtering feature in hime's github :) Are you talking about stuff related to the following https://github.com/caleb-/hime/tree/master/filter Yeah, ibus does lack such feature currently.
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. I'd say this reminds me of the way Win32 IME works. Simple Win32 IMEs are just dynamically loadable modules. While sophisticated ones have servers and use some sort of IPC. Please correct me.
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. I'd say I agree that it is not that relevant 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. Yeah, I know I'm still a dummy in IM/IMF world. Thank you for your previous correction. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org