Re: Concerning Keyboard Status Menu

[Ma Xiaojun <damage3025 gmail com>]

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.

>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?
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.