Re: Some points about IM integration

[Weng Xuetian <wengxt gmail com>]

On Tue, May 15, 2012 at 11:39 AM, Owen Taylor <otaylor redhat com> wrote:
> On Tue, 2012-05-15 at 10:12 +0800, Weng Xuetian wrote:
>
>> > All of the above is an argument only for picking a single input method
>> > framework. It doesn't say anything about what input method framework we
>> > should pick. The fact that the IBus developers have been engaged with
>> > GNOME for quite some time and are willing to work with us to create a user
>> > experience that is simple and consistent with the GNOME principles is
>> > certainly a big plus, but we do need to make sure that the end result
>> > works well as well as looking good.
>> >
>>
>> First let me clarify a question though nobody ask, but I think you
>> have this question in mind. That is "why not fcitx work with ibus,
>> isn't that a feasible solution too?".
>>
>> It's kinds of the same question why there are so many distribution for
>> linux? There is some reason important that make two similar projects
>> are not the same projects. Though from some other people point of
>> view, they don't understand or don't know the  reason. To make it
>> simple, the reason that it's impossible for ibus to implement the
>> feature I want in input method.
>
> I think it's quite interesting to learn about the differences in
> philosophy and the differences in technical decisions between projects.
>
> But certainly suggesting that people stop working on their projects
> or merge efforts is generally not reasonable. (We've all heard plenty
> of people saying "Wouldn't it be great if GNOME and KDE merged" over
> the years...)
>
> Once projects have been around for a while they have their own
> philosophies, their own users, their own history. So I'm not expecting
> anybody to give up work on their own projects.
>
> But that doesn't mean that we can simply be neutral, work with all
> projects equally. I think the end result of that is poor integration,
> poor user interfaces, and unhappy users.
>
> [....]
>
>> And for example, the keyboard layout integration, settings is actually
>> duplicated there and within ibus, and the UI even not cover all
>> available option inside.ibus. My point is, why not let input method
>> guys to implements theirs own gnome-control-center module? This should
>> be the right way to go. And much more easier and decouple with GNOME
>> core, and will works even better. What you guys choose now even limits
>> ibus itself from my view.
>
> For the GNOME philosophy on configuration, see the section called
> "The Question of Preferences" in:
>
>  http://ometer.com/free-software-ui.html
>
> In general, we wouldn't believe that giving the user more options is
> necessarily better. Even as something as basic as the list of
> possible input methods is something that we think needs careful thought
> and planning. When I look at the screenshot at:
>
>  http://fcitx-im.org/wiki/File:Fcitx-configtool.png
>
> I would certainly wonder if including a Dvorak layout for Cameroon makes
> sense. (The equivalent part of the UI we're working on can be found
> https://live.gnome.org/Design/SystemSettings/RegionAndLanguage -
> under Input Sources, but I'm not sure if there are more current or
> more extensive designs elsewhere)
>
The default option of "current language" is selected.
By the way, it's still kinds of UI design but not internal problem.
When I want to go further I would also rethink about the UI part.
>> And from my point of view, setting interface of ibus is hardcoded, so
>> those pygtk setting code must be replace one by one if they want to
>> move to another toolkit (even from gtk2 to gtk3). And make it
>> impossible to put the setting just "inside" the gnome-control-center.
>
> Are you saying that fcitx generates the configuration GUI based on
> a description? In general, our experience has definitely been over the
> years that auto-generated configuration have some downsides. They
> don't allow customized design of controls for particular options, and
> don't handle the interaction between interacting options well.
>
fcitx doesn't force this, external command would be allowed. But for
common case it's quite a lot easier to integrate with UI better.

> I don't want people to draw the conclusion that because I'm saying that
> input methods should have simple configuration without a lot of options,
> I think that they aren't important. I'm very aware that every single
> user that comes to GNOME and wants to write in Chinese needs to use an
> input method. But if we have so many options that the defaults don't get
> well tested, or if options conflict and produce bugs, then we're not
> shipping a good ';';'''''''
> '
Options are really required in order to meet people need especially
for input method. This is a basic components for people.

This shows your poor understand on input method, when you look at
Chinese Pinyin, you might found a lots of option (say more than 10-20
about pronunciation) are useless for common people, but others CANNOT
use it correctly without such options. This is the same case of
"accessibility" part in desktop.