On Sat, Nov 24, 2012 at 9:30 AM, Giovanni Campagna <scampa.giova...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list