Re: Concerning Keyboard Status Menu

[Giovanni Campagna <scampa giovanni gmail com>]

2012/11/24 Ma Xiaojun <damage3025 gmail com>:
> Hi, all.
>
> This thread is about engine property filtering rather than engine list
> filtering.
> Though we discussed engine list filtering and many off topic issues, anyway.
>
> Wanna know why engine property filtering can cause serious regression
> on CJK inputting experience?
> Please check my videos recored on GNOME 3.4, Fedora 17 and GNOME 3.6,
> Fedora 18 (installed from Alpha and did entire system update),
> respectively.
> http://dl.dropbox.com/u/45139465/gnome34.webm
> http://dl.dropbox.com/u/45139465/gnome36.webm
> ( There is no sound/voice at all. And I'm not savvy in video tutorial
> business at all. )

Hi.
Thank you for you time to record those videos, and thank for your
valuable input in this difficult matter.
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.
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.
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.
Looking at anthy or hangul, it seems that the coordination that
happened (or that was forced upon) was beneficial to both projects.
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.
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.

Thanks in advance for your work!

Giovanni