Re: Some points about IM integration

[Owen Taylor <otaylor redhat com>]

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)

> 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.

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 ';';'''''''
'


- Owen