Re: Some points about IM integration

[Tommy He <tommy he linux com>]

On Tue, May 15, 2012 at 2:05 PM, Weng Xuetian <wengxt gmail com> wrote:
> On Tue, May 15, 2012 at 1:42 PM, Tommy He <tommy he linux com> 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 <wengxt gmail com> wrote:
>>> On Tue, May 15, 2012 at 12:52 PM, Germán Póo-Caamaño <gpoo gnome org> 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
>>> desktop-devel-list gnome org
>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>>
>> --
>> Take a Deep Breath out of Windows



-- 
Take a Deep Breath out of Windows