On Tue, May 15, 2012 at 11:39 AM, Owen Taylor <[email protected]> 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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
