Hi, On Sat, May 12, 2012 at 10:51 PM, Owen Taylor <[email protected]> wrote: > Hi Maguerite, > > Thanks for the detailed response! > > It's hard for me to talk about the pros and cons of fcitx and IBus - > sadly I don't speak or write Chinese, and I haven't investigated the > technical operations of these systems either. > > But what I do want to talk about is the user experience we try to create > in GNOME. In general, our goal isn't maximum choice. It's the best > possible experience. > > A user starts using GNOME. They have trouble inputting Chinese text. > A friend sees their computer, tells them to uninstall IBus and install > fcitx. Things work much better. Is this a success of Free Software? > No - it's a failure. We gave the user an operating system that didn't > work until someone fixed it. >
These are _almost_ correct for GNOME, and it has self-explained why it's a bad idea. Most GNOME developers aren't CJK users, so making any assumption can be really risky. It's not that simple to say whether a "working" input method framework is good enough for average CJK users. Tremendous strides have happened in the field of input method on other platforms, say Windows, iOS and Android. Those progress are not acknowledged by most Linux desktop vendors (either upstream ones like GNOME, or downstream distributions) in recent years. This leads to an embarrassing situation of Linux desktop input methods - developers tend to think the ability of inputing characters is the only important thing, and user experience researchers look only at how existing Linux users do with existing input method frameworks. This is troublesome, because we've already lagged behind but we're still trying to build our own wheels, without the desire of knowing how others have already done. > In my experience, there is almost no chance most users will understand > the concept of an input method framework. Users are busy talking to > their friends, doing school work, or inventing the cure for cancer. They > don't want to take a course in how their computer works internally. We > can provide options behavior - are they using Pinyin or the Four-Corners > method? But we shouldn't give them options for how applications talk to > the input method. > True, users usually don't care about what's input method framework, less about how it talks to other applications they are using. But they do care about many details of the functions, like defining own shortcuts, modifying the details of candidate ordering, add or delete some words from dictionary, how the user interface is displayed and how the candidates are shown (in very very detailed manner), whether they can sync there user-defined settings to the cloud so it's ready wherever they need them, etc. What is a "good" input experience is not kind of thing that can be easily imagined base on existing assumptions among Linux desktop developers because users are so nit-picking on other platforms already. They do care about whether the stuff works, but it's basic thing anyway; they also care about whether his/her stuff is cool, which includes but not limited to easy retrievable/changeable skins, hot words live updates, cloud candidates words, etc. Some people even change the skins in a timely fashion, say one day/week per skin - and it's important that doing so is too easy, just browse the online library and click, all done. If you do visit the offices of non-IT companies in China, you'll find what I've described is too few comparing what they have and use everyday. > We also really value using the same basic components on all GNOME > systems. You hit a crash on your system in GNOME Shell when using > fcitx, and you report it in GNOME bugzilla. If I'm using fcitx, then > I can reproduce the bug and fix it. If I'm using IBus or no input method > framework, then the bug may never be fixed. > > Users should also be easily able to mix and match and switch between > languages. This means that we need an input method framework that works > well for all the input methods - we can't have one input method > framework for Chinese, and another for the languages of India. > Yes, but why not making the integration a plug-able system? Providing an interface that input method frameworks can talk with, for example gnome-control-center. I read there are people saying they want to end the diversity/mess of input method framework in GNOME by doing so, but we all know such decision can't be made by developers in reality, users will choose whatever they feel more comfortable. It's good to recommend and promote something for collaboration, but it's definitely bad to bond to something with the risk of being irreplaceable in the future. Input method is something unique than other applications like music player because of its nature of talking with all applications that user needs it to. > So, please make the argument that fcitx is better and more aligned with > the philosophy of GNOME and should be used instead of IBus! > Even with the above concerns, I vote for Fcitx if we have to make a choice. Let me start with your sample questions: > The best way to make that argument is to explain it to us - > > * Does fcitx allow for an easier-to-understand configuration user > interface? Do you have screenshots? > Yes, and screenshots are already shown by Weng. The UI still needs some input from professional designers to make it better fit into the desktop. > * Does fcitx have better feedback to the user while they are entering > input? > Short answer: Yes. Input speed, input time and character count are shown by default for Chinese users. There is almost no overhead to support features like this because there is an integrated plugin system in Fcitx. Input method engine developers can focus on implementing core algorithms, other common functions like the way of dealing with punctuation, skin support, cloud integration, quick phrase, full width character switch, are automatically added at runtime whenever possible by the framework. The overall architecture of Fcitx is highly modularized with well abstracted layers of functionality. Above is an example of the advantages brought by such architecture. > * Does fcitx have better dictionaries and algorithms in its input > methods? > Short answer: No. All existing input method frameworks share almost the same dictionaries and algorithms. There are minor differences in a framework's default PinYin engine, so scim-pinyin, ibus-pinyin and fcitx-pinyin are not the same thing. But comparing with more advanced, dedicated PinYin engines like Sunpinyin and Libpinyin, they are just providing similar features with similar experience. > * Is fcitx less buggy? > Bugs always exist, but most noticeable bugs affecting input experience are in X and UI toolkits, not in IBus or Fcitx. Here are several obvious/long-standing examples: 1.GTK+ 3 reuses the variable GTK_IM_MODULE, which has already caused a lot of pain for distribution makers. When GTK+ 3 IM Module aren't available on system, but GTK_IM_MODULE variable is set, all GTK+ 3 based applications lost input method support. This can be workaround by always installing GTK+ 2 and GTK+ 3 IM Modules together. But users tend to be unhappy with increasing dependencies. Qt4 has a separated variable QT4_IM_MODULE to distinguish from Qt3's QT_IM_MODULE when needed. 2. The first problem can be tolerated in some degree if GTK+ 3 can properly fallback to XIM when GTK_IM_MODULE is set but not usable. But it didn't work for a long time. And XIM support in GTK+ 2/3 isn't that perfect (comparing with Qt4) at any time. 3. We have asked that key events must be passed to input method framework before passing it to anything else, but the request is always ignored. This makes many applications "eat" some random key events while the event is important for specific user experience. -- Regards, Aron Xu _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
