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
