On Tue, May 15, 2012 at 2:05 PM, Weng Xuetian <[email protected]> wrote: > On Tue, May 15, 2012 at 1:42 PM, Tommy He <[email protected]> wrote: >> I'm just start catching the whole story and find where the discussion is now. >> >> On Tue, May 15, 2012 at 1:07 PM, Weng Xuetian <[email protected]> wrote: >>> On Tue, May 15, 2012 at 12:52 PM, Germán Póo-Caamaño <[email protected]> wrote: >>>> >>>> Is it possible you can enumerate all those special needs and why are >>>> compulsory? >>>> >>>> Just stating the options are important does not help to understand why, >>>> neither gives the opportunity to think or determine which approach would >>>> fit better. >>>> >>> Well, since we already agreed on option complex but necessary is >>> required, we need not to continue on this question. >>> >>> But if you want I could explain it. (Note that both fcitx and ibus >>> have such option, so it's not about functionality but about UI.) >>> >>> Pinyin is an input method based on Pronunciation of Chinese character. >>> But Chinese people have quite different accent in different place, so >>> they might not be able to distinguish some pronunciation, for example >>> "si" or "shi". So they are option to let input method think si and shi >>> is the same string to lookup. Number of similar options is nearly 20, >>> I think we could think this as "Complex". For the number of people who >>> need it, it is much lesser than people who don't need it. But we >>> cannot remove them since it's necessary for those people. >> >> Now we're back to a specific input method, again. >> From my perspective, these options should be considered as input >> method engine options. >> >> I assume that proposed IM configuration module in gnome-control-center >> will ONLY presents the options for input method *framework*. Correct >> me if I'm wrong. >> As long as it have a button to launch the input method engine >> preference window AND doesn't shut the door from engine developer to >> customize, I don't see it as an issue. > > You totally get my meaning wrong, I mean shutdown down the door for > other IMF, and the code is mostly in gnome-settings-daemon since it > looks like gnome want to force gtk-im-module settings.
Nope, I was not talking about this one. Sorry to mention that I'm kind of agree that there should be a single default IMF, not multiple. There needs to be a default IMF integrated into GNOME. It's the way I believe to bring i18n users to same level as others. This default IMF should have tightly correspond with a single UI module in gnome-control-centre, which presents all IMF level tweaks. However the Preference window for a given input method engine should not and can not be unified. It had better to be left to the hands of input method engine developers. What I am NOT suggesting is that this default IMF would be iBus nor FCITX. Maybe neither of them. After reading this long thread, there's still no concrete proof on how supreme FCITX is on the core feature sets of IMF. BTW please don't hesitate to list them here. The reason I am asking is that in practice we need to figure out which one is more suitable to choose as the reference IMF. There has to be a referenced one, either slightly modified iBus, slightly modified FCITX, or even a complete new one written from scratch. Just one, not two or multiple. Another thing I am NOT suggesting is that shutting the door for other IMFs. During the development of the reference IMF, we should declare what kind of behaviors GNOME would expect from a IMF so that a thin wrapper could be developed later for other non-default IMFs. The non-default IMF should be allowed to add its own configuration module into gnome-control-centre while disabling the default one. >> >> If so, I'm curious on how many tweaks in a certain input method >> *framework* are available to end users in runtime. How many are there >> in iBus and FCITX respectively? > > Fcitx have more, but that's for "Global" configuration, which ibus > usually provide them for each input method engine. I see your point. FCITX seems to pull more common options from input method engines than iBus and listed them as "Global" configuration. It might be good, but might also increase the coupling, if I'm allowed to say. > The most difference of philosophy of ibus and fcitx is, for ibus, the > only type of plugin is just engine, and standalone with each other. > For fcitx, plugin is not only engine and they should cooperate to > provides better input feeling. I'm afraid it's still a bit vague. Are you saying that in FCITX by enabling plugin A AND plugin B, there will be more options than combining enabling plugin A and enabling plugin B individually? >> >> Otherwise, I'm afraid that we may never consolidate a unified UX for >> IM configuration module since the input method engine options vary >> vastly. >> > >> ______________________________________________ >>> desktop-devel-list mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> >> >> >> -- >> Take a Deep Breath out of Windows -- Take a Deep Breath out of Windows _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
