Another Input Methods introduction slides -- http://goo.gl/ag7gX
On Mon, May 21, 2012 at 10:09 AM, Peng Huang <[email protected]>wrote: > Hello everyone, I am one of IBus owners. Please allow me to feed some > information for IBus. > > * http://goo.gl/9LlX5 , here is a doc which gives some background of > ibus project. > * IBus is bus central multiprocess architecture, benefits are: > ** Engines are separated by system process. > ** Engines can not affect each other. > ** Engine can not access data from other engines and IMF. > ** One engine can not crash whole IMF. > * IBus is well maintain project and IBus community is very active. > ** Changes for ibus from 2012-01-01 (framework only, does not include > each engines): 239 files changed, 34665 insertions(+), 31937 deletions(-) > ** https://github.com/ibus/ibus/commits/master > * IBus is a well managed project, we have good code review process to > guarantee code quality. http://goo.gl/Gw8qQ > * IBus supports CJKI and 30+ languages (Sorry I can not get accurate > number). > * IBus supports handwriting as well. > ** http://code.google.com/p/ibus-handwrite/ > ** https://github.com/yusukes/ibus-zinnia > * Most major Linux distributions are using ibus. > * Chromium OS is using ibus as IMF. Chromium OS community contributed > many efforts to ibus as well. > * IBus is very popular in CJKI and etc. http://www.ohloh.net/p/ibus 235 > users. (Comparing 11 users of fcitx http://www.ohloh.net/p/fcitx) > > Comparing fcitx with ibus > * fcitx was developed as Chinese input methods from beginning. In other > words, the origin project goal is not IMF. > * IBus was developed as IMF from day one. > * fcitx is using single process architecture. The single process > architecture is not suit for IMF. It has been approved by SCIM and other IM > projects. That can not be resolved without re-implementing it from scratch. > * Some Chinese IMEs of fcitx may have better UX than engines for IBus. > But ibus is only a framework. It is not Chinese input method. We can > improve or provide Chinese IMEs in separate projects for IBus. > > IBus update: > * In ibus-1.5, Python UI is replaced by vala language implementation. > Vala will be translate to C. So it has similar performance and memory foot > print of C language. Only setup UI is python. > * Python pinyin engine has been replaced by C++ version in 2009. Only > setup UI is python. > > > Peng Huang > > > On Thu, May 17, 2012 at 11:49 PM, Ma Xiaojun <[email protected]> wrote: > >> Hi, all. >> >> Let me summarize the concerns of Chinese community: >> >> GNOME is integrating ibus. This may prohibit the possibility of using >> other IM frameworks/servers. Worse, this may lead to an unusable >> release of GNOME. >> >> And ibus sucks. Because: >> 1. Some engines are written in Python therefore slow by nature. >> 2. Chinese mode stuff can be tricky for Traditional Chinese users. >> https://github.com/acevery/ibus-table/issues/9 >> 3. gcin/hime is more close to Windows's default input methods for >> Traditional Chinese. >> 4. Various reasons show that fcitx is superior to ibus for Simplified >> Chinese user. For example, ibus-pinyin lags. >> >> And ibus is not well maintained. An evidence can be a long list of open >> issues. >> http://code.google.com/p/ibus/issues/list >> >> Many people believe that recent ibus releases are just fixing bugs and >> there won't be new fancy features in ibus any more. >> In the mean time, fcitx is actively developing fancy features. >> https://www.csslayer.info/wordpress/ >> >> Though we may be 100% sure that alternatives like fcitx is definitely >> better. Integrating something that is known to be sucks and not >> future-proof is counterproductive and meaningless. Experienced Linux >> users are used to the ups and downs of various IM frameworks/servers >> so they do value freedom of choosing IM frameworks/servers. >> >> Last but not least, ibus and fcitx are not mutual exclusive in runtime >> since there is Kimpanel. We can switch between fcitx-pinyin and >> ibus-pinyin dynamically. So the UI/UX improvement of integration is >> kind of trivial. >> >> Please correct me. >> >> But why don't people help improving ibus? >> >> Because people believe that Weng Xuetian and his friends are among >> very few FOSS people that master input methods stuff. Reporting issues >> to ibus doesn't work. >> And they are developing fcitx. >> The same should apply to the maintainers of gcin/hime. >> And people don't believe GNOME project members can actually help the >> development of input methods stuff. Even if ibus is "upgraded" to a >> GNOME project. The situation is the same. >> >> We all know it's engine rather than framework matters. But it's not >> Windows where ISVs actively developing apps on cryptic APIs. IMF >> maintainers also try their best to produce excellent engines. If Weng >> released a new fancy engine that is naturally only available in fcitx. >> Then people want to switch framework. >> >> When I say "believe". I mean there may not be strong evidence. But >> that is the image among users. I support any actions that can make >> things better. But things are quite tricky this time. >> >> Best Regards, >> Ma Xiaojun >> _______________________________________________ >> desktop-devel-list mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > >
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
