GNOME.org
 

Re: Some points about IM integration

I want to add more background on ibus as I watched Huang Peng developed it from scratch back to few years ago in Beijing.
One of the main ideas behind ibus was to implement The Specification of the IM engine Service Provider Interface which was jointly developed by CJK(China, Japan, Korea) IM developers/experts through Northeast Asia OSS Forum[1]. You might still find the specification online, otherwise I could help to find the doc and post it here. The specification itself was coming from about 2 years discussion among the best IM developers from China Japan and Korea at the time.
Ibus was firstly written in python initially as the proof of the concept of the CJK IM specification, later on rewritten in C to provide the necessary performance, mostly following the ideas from the specification. So, ibus had inherited all of the best practice coming from all CJK countries.
So, I am here want to purpose, it is probably a time for all of the input method developer to concentrate on a unified input method framework, CJK IM specification is a very good starting point, then let's focus more on the input engines(such as pinyin or wubi). 

Shao

[1] http://www.neaossforum.org/

On 05/15/2012 07:27 AM, Owen Taylor wrote:

In general, choice of input method framework is not a goal in itself.
If we choose a single input method framework to integrate with GNOME -
that doesn't make GNOME like proprietary software from Apple and Microsoft,
because GNOME will still be 100% Free Software, and will still be developed
in the open by the GNOME community.

GNOME doesn't want to work well just for tweakers and enthusiasts - it's
very important to the project that GNOME works well for all users without
tweaking. We want to give the choice of using Free Software to
everybody - this is a much more fundamental form of choice than giving a small
group of users the ability to swap out a different input method framework
underneath GNOME.

GNOME isn't just a set of parts that a Linux distributor takes and uses
to create a working system - we also take responsibility for creating
a fully working system. This means deciding how GNOME interacts with
system components like sound and networking and printing and when necessary
enhancing those components to provide the right experience to the user.

So we can't leave it up to one Linux distributor to combine GNOME with
fcitx to make a version of GNOME that works well for zh_CN and another
Linux distributor to combine GNOME with RIME or hime to make a version
of GNOME that works well for zh_TW. We want GNOME to, without customization,
work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

Of course, it would be a mistake to think that a small group of English
speaking developers could make GNOME work well in all these languages. That
would be impossible! But from experience, we know that simply leaving a
problem like this to external developers and hoping for the best doesn't
work out well. Instead we need to engage users and developers from these
language communities into the GNOME development community.

I don't want to minimize how easy that is - I know there are very significant
barriers of language, timezone, and distance that make this hard. I know
that bugs get ignored and patches sit around unreviewed. But still,
active engagement is the only way forward. I think it's absolutely wonderful
how many people have gotten involved in the current discussion!

We also need to keep in mind that we aren't talking about the choice of input
method, we are talking about input method *frameworks*. The basics of passing
events from application to daemon, loading different input method backends,
handling hotkeys and displaying feedback are going to be very similar for
all East Asian languages.

Things like displaying feedback may be a little different if we move further
afield to Thai or Hindi - but still, there is no fundamental reason that they
need a different *framework*.

Using a single input framework for all GNOME users has many benefits.
GNOME developers can reproduce bugs that users run into. Bugs only have to
be fixed once, not in multiple frameworks. We can actually figure out how
to make input methods work with onscreen keyboards and accessibility. Our
designers can collaborate on making the configuration dialogs conform to
GNOME standards.

Finally, using a single input method framework is pretty much essential to
the goal of allowing users to configure languages at runtime with a nice user
interface. If language A and language B require different input method
*frameworks*, there is no way that the user can switch between them with a
hotkey.

In general, I don't see standardizing D-Bus interfaces so that GNOME can
work with multiple input method frameworks as being a useful activity.
If the D-Bus interfaces are carefully maintained and changed only with
agreement and advanced notice, then they will impede the progress of bug
fixing and making things better. If the interfaces are not carefully
maintained, then they aren't standards at all, and users will constantly
encounter breakage.

And in any case, as described above, there has to be *one* framework that
works as well as we can possibly make it for all users. Multiple partially
working frameworks are not a substitute.

All of the above is an argument only for picking a single input method
framework. It doesn't say anything about what input method framework we
should pick. The fact that the IBus developers have been engaged with
GNOME for quite some time and are willing to work with us to create a user
experience that is simple and consistent with the GNOME principles is
certainly a big plus, but we do need to make sure that the end result
works well as well as looking good.

- Owen


_______________________________________________
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]