Re: Some points about IM integration
- From: Aron Xu <aronxu gnome org>
- To: Peng Huang <shawn p huang gmail com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Some points about IM integration
- Date: Tue, 22 May 2012 08:22:59 +0800
Hi,
On Tue, May 22, 2012 at 12:43 AM, Peng Huang <shawn p huang gmail com> wrote:
> I am glade to hear you also think ibus is a good choice right now. And we
> were discussing and working on IM integration with gnome community from
> 2010. We really want to get some progress instead of waiting forever.
>
I didn't mean anything that any IMF is bad, and IBus is particular
outstanding as its initial design and further implementation are
proofed by a large user base than Fcitx or any other (except SCIM, but
it's out of scope here).
Of course I know that people would like to see progress on doing
something, but IMHO currently the result can be frustrating.
> And I also think it is a good to integrate gnome desktop with an IMF as soon
> as possible, because we can get user feedback and find some really problems
> early. And then we could continue improving it.
>
As said in previous E-mail, this result is so theoretical. If other
parts GNOME is willing to improve user experience of IMF, they should
already be working on fixing bugs in GTK+, which are usually something
that IMF cannot work around. Improving the appearance of input
experience is something good, but IMHO we are on the wrong way.
Also there is concern that users of other IMFs will be ignored,
because "man power is limited". In the end, if another IMF expose a
problem in some GNOME software, the users will be told to use IBus or
go away. This result is extremely unfriendly and is probably going to
make more users leave.
IMF users are mainly CJK, and Chinese has a very large share. If GNOME
want to keep those users, and corporations behind GNOME would like to
see their products to be accepted by more CJK users, then GNOME will
need to have a look at what leading input method providers do on other
platforms to improve experience.
Here are two sets of screenshots of Sougou Pinyin and QQ Pinyin on
Windows. The user count of these two input method is larger than GNOME
all over the world (just some rough calculation):
https://live.gnome.org/InputCJK/Windows/Sougou
https://live.gnome.org/InputCJK/Windows/QQ
I agree some features present above are not needed, but the overall
appearance is representing what's a modern input "experience".
> And I also believe Fujiwarat's patches will not forbid using other IMFs with
> gnome 3. We already considered it. Even if in future, GNOME 3 decides to
> replace ibus with a new better IMF, it should not be difficult. And most
> source code could be reused. And the new IMF could learn from the IM Gnome
> integration as well. It could benefit both IM and Gnome communities.
>
I had a quick look at the code on git.gnome.org, which seems not
written by fujiwara, it does not prevent the use of other IMF but when
users use xkb and IMF together, they'll get a not working environment.
Such breakage is cased by other GNOME developers' poor understanding
of "how IMF works", and it's obvious they don't use IMF everyday so
understandable. Weng has already started a conversation with Rui Matos
to help him improve the status, but I haven't seen any new commits.
> I don't think support multi-IMF at beginning is a good idea. It need much
> efforts which can not be afforded right now. I think workable way is
> integrating with one IMF at first, and may support multi-IMF in following
> iterations. I think IM communities will contribute those efforts.
>
IMHO the reason we need such workload to _integrate_ IMF to GNOME is
because there are technical design flaws in the project, which make
developers and users have a hard time in the name of experience.
> I hope Gnome could become more non-technical user-friendly, and Linux be
> successful in Desktop area as well.
>
We are continuously moving forward, but never give users a "good
enough" experience, one of the reasons is that we are continuously
breaking existing efforts.
--
Regards,
Aron Xu
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]