Re: Concerning Keyboard Status Menu

[Ma Xiaojun <damage3025 gmail com>]

On Thu, Nov 22, 2012 at 3:22 AM, Bastien Nocera <hadess hadess net> wrote:
> On Thu, 2012-11-22 at 03:01 -0600, Ma Xiaojun wrote:
> <snip>
>> Stop destroying IBus by making it GNOME-proprietary, please.
>
> I don't think anyone will read your e-mails if you keep coming up with
> statements like that.

I can understand if 3.6 has some glitches in IM integration, that's normal.
But some of your unprecedented sh*t like engine list filtering and
engine property filtering makes GNOME input system quite
'proprietary'.
The way of doing things in IM aspect is fundamentally flawed.

IBus is a framework that allows people to develop engines in
(hopefully) friendly way. You can develop very fancy one as well as
very crappy one. User can install whatever engines they want. That's
open and non-proprietary.

Some 'third-party' engines I know:
http://code.google.com/p/rimeime/
http://code.google.com/p/libgooglepinyin/
http://code.google.com/p/ibus-cloud-pinyin/
(This one is a little outdated, I'm trying to port it to support
recent IBus version.)
http://code.google.com/p/ibus-t9/
(I haven't tried this one.)

For engine list filtering, the list itself is OK. But the way you
enforce it is fundamentally flawed. Your should recommend the list to
distributions and that's it. Don't think 'third-party' engines are
some geeky stuff. It's probably the case in Hong Kong. But not the
case in Mainland (and also Taiwan I believe). It may not be that easy
to find a single young, not so young, Mainland Chinese people using
Windows' built-in engines. We cannot change the fact that Linux is
lack of good engines, but please don't make the situation worse that
even existing 'third-party' IBus engines become harder to install.

For engine property filtering, it's completely non-sense. Are you
trying to become a steering committee that decide which property is
allowed and which is not allowed? What you should do is that polish
the supported engines and leave third-party engine as is. Even if you
argue that ibus-table has no upstream so it cannot be catered. What
about ibus-pinyin/ibus-libpinyin and ibus-chewing? Which are much more
popular and have known upstreams.

Chinese engines, in generally has the following properties need to on the fly.
Conversion (Chinese) or not (English).
(Some people prefer this switch rather than switch the engine altogether)
Half-width or full-width
( For example，。：； vs ,.:; )
( Chinese writing need full-width symbol but many computer related
place only accept half-width symbol, say Shell, Python, ...)
Simplified or Traditional
( For example 郁闷的乌龟 vs 鬱悶的烏龜 )
( You can think of it as lower/upper case, hiragana/katakana with both
set have thousands of *common* character. )
( In theory, one only needs either Simplified or Traditional, but
chances are that we communicating with different people so we
different variation. )

I'm not unwilling to hack code and submit patches. But what I would
like to do is eliminate the stupid filtering altogether. So related
the developer must understand why it is the case.