Re: Some points about IM integration



Another Input Methods introduction slides -- http://goo.gl/ag7gX



On Mon, May 21, 2012 at 10:09 AM, Peng Huang <shawn p huang gmail com> 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(-)
 * 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. 
 * 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 <damage3025 gmail com> 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
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]