2012/11/24 Ma Xiaojun <[email protected]>: > 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
