Re: Concerning Keyboard Status Menu

[Mike Qin <mikeandmore gmail com>]

On 24/11/12 01:06 PM, Ma Xiaojun wrote:
> On Sat, Nov 24, 2012 at 9:30 AM, Giovanni Campagna
> <scampa giovanni gmail com> wrote:
> > I think they are very helpful for us who are not used to chinese
> > input, and I also think they make clear the set of switches one needs
> > to type chinese is greater than the boolean lang / english that us
> > westerns are used to.
>
> I'm glad that you do understand now.
>
> > For testing purposes, I managed to restore the 3.4 experience (as much
> > as I understand it), by implementing the remaining property types, and
> > temporarily removing the whitelist. I must say that to me, the set of
> > exposed properties is conceptually limited and reasonable.
>
> Thank you for your work.
>
> > On the other hand, the properties don't seem to be implemented with a
> > coherent UX in mind. For ibus-libpinyin, the items are exposed as
> > simple symbols, although they are shown in a large menu. Also the
> > items are sometimes confusing because they refer to current state but
> > they ask to appear as an action.
>
> This is due to historic reasons, please check my comment here.
> https://bugzilla.gnome.org/show_bug.cgi?id=688916#c7
>
> > Looking at anthy or hangul, it seems that the coordination that
> > happened (or that was forced upon) was beneficial to both projects.
>
> Yes, I want coordination.
> I'm subscribing ibus-devel (it has Google Code issue tracker
> forwarding E-mails), ibus-user, libpinyin mailing list. And I
> occasionally check libpinyin's Github page.
> But I haven't noticed related requests for ibus-chewing, ibus-pinyin,
> ibus-libpinyin, ibus-table.
>
> > Additionally, the set of properties (chinese or not, simplified or
> > traditional, full or half width, full or half width symbols) seems
> > simlar in both ibus-libpinyin and ibus-table.
>
> Yes.
>
> > Therefore I'm proposing a compromise: would you, as a developer of the
> > affected IMEs, accept to change the property keys to a common
> > "standard" that we can then whitelist, restoring the functionality
> > that was lost during the transition? Would you also talk with the
> > designer or accept designer input about the best way to expose those
> > choices (i.e. as a switch, as an action, as a submenu, etc.)?
> > That I believe would be the best of both worlds, and would really show
> > the advantage of working closely togheter towards a great user
> > experience for Chinese users.
>
> Yes and No.
>
> Yes, for consistency ('standard'). I definitely welcome input from
> you. I don't think current 3.4 experience is good enough either.
>
> No No for white listing.
> White listing would destroy the philosophical and practical openness
> of IBus ecosystem.
>
>  From philosophical point of view, you are doing moderating /
> censorship here. I hate that, at least. It reminds me something like
> every app has to have approval from 'App Store'. I believe that a free
> (as in freedom) 'market' works much better.

And you all know how Chinese hate nonsense moderating/censorship. :)

In this case, blacklist the input method statically means GNOME will be 
forbidding the issue emerge to the developers. Developers lost their 
chance to improve their stuff. New input source will never be developed, 
because no user and developer is able to test that.

>  From practical point of view, it prohibits effective engine
> development. Since engine authors have to communicate with both GNOME
> upstream and countless downstream. Why downstream is countless?
> We have several major distributions, some of them are more
> conservative about stable update, e.g, Debian and Ubuntu.
> Even if many minor distributions may use major's distributions
> repository. What if they happen to fork GNOME Shell for eye candy and
> other purposes?
> Some minor distributions are regional and their community are not
> communicating in English. Then what can a Chinese developer (whose
> second language is almost always English) do?
>
> You are not solving a real problem here by using white list.
> As I said, current text labels not being good enough is due to historic reasons.
> If you check now deprecated color icons, they are quite clear. (Except
> some icons from ibus-table)
>
> Chinese end users (consider general computer end users here) are not
> bothered by 'inconsistent' third-party engines. Popular engines in
> other desktop OS are 'inconsistent'. If they are consistent with
> built-in engines and not innovative enough, why people switch?

Well, if it's consistent, it's better. Isn't it?

The thing for Chinese input method is: Few of them are doing a good job. 
Styling of Chinese, dialect, modern Chinese cultures idioms *varies*. 
Even the big commercial input method failed to achieve a good job on 
every aspect mentioned above. That's why you saw several of commercial 
input method installed even on a single user desktop. This is why input 
method tend to be inconsistent.

The default pinyin input GNOME whitelisted is ibus-pinyin. It's a very 
basic input engine that doing a relatively poor job on almost every 
aspect I mentioned above. And I'm not being offensive to those 
developers, Sunpinyin is no better than that.

Develop a Chinese IME is *extremely* hard and it has commercial 
barriers. Big search engine companies have much complete training 
dataset than any opensource organization, commercial dictionaries from 
Chinese internet media companies are covering every aspect of Chinese 
culture: ancient poetry, modern word, idiom...Companies like Microsoft 
and Google have a much more sophisticated Machine Learning Research 
Group than any opensource organization...

Therefore, banning other free software approach to Chinese input engine 
is a very dangerous thing to free software. We're already in a pretty 
bad scenario, banning other approach is a *great discourage* to those 
developers and the gap between commercial input engine and open source 
input engine will become larger and larger.

> What end users really want is high conversion rate and configurability
> to cater their special need.
> I don't want to receive doubts here since I do believe I know better here.
>
> BTW, I'm not owner of any engines, but I can send pull requests and I
> sent some for ibus-table.

I'm the maintainer of ibus-sunpinyin. I could be testing and fixing any 
issues happened during this integration.

But in that case, you have to at very least, stop banning 
ibus-sunpinyin, which is not on your evil whitelist currently, otherwise 
I cannot test anything.

> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

--

Thanks
Mike