Re: Some points about IM integration

[Aron Xu <aronxu gnome org>]

On Wed, May 16, 2012 at 2:19 AM, Bastien Nocera <hadess hadess net> wrote:
> On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
>> On Wed, May 16, 2012 at 12:54 AM, Olav Vitters <olav vitters nl> wrote:
>> > On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
>> >> Q: "What are GNOME people doing?"
>> >> A: "1.Super-excellent ideas and design;"
>> >> "2.Poor implementation;"
>> >> "3.Working hard on fix-ups and finally it works;"
>> >> "4.Immediately starting to re-invent wheels from Point 1."
>> >
>> > Cool that you have that idea, but raising things like this is *not*
>> > related at all to the subject. Either be specific, or don't post.
>> >
>> > I have zero interest to see things about how GNOME might be viewed as
>> > well as your thoughts on GNOME OS.
>> >
>> > You mentioned not wanting to start a flame war. Please also don't start
>> > one yourself.
>> >
>>
>> As you are one of the moderators, please don't try to blame someone
>> based on your very first impression, read the whole post and you'll
>> find whether it's related. What you have just quoted is "rumor", but
>> it is something that happens right away as far as I can see for IMF
>> related issue here:
>>
>> 1.GNOME is trying to have IMF integration - cool stuff.
>> 2.But it is warned by specialized people that the plan is broken - can
>> lead to poor implementation and breakage.
>> 3.People insist on having it right now for 3.6 - then must work hard
>> on fix-ups in the future.
>> 4.As said before, if IBus is getting replaced - then re-work the whole thing.
>
> If IBus gets replaced, then it gets replaced. Code doesn't just
> disappear and I'm pretty sure that code can be adapted rather than
> completely trashed and having to restart from scratch.
>

This is not a strong claim because you even don't have the basic ideas
about input methods right now, which is the reason for why I want all
the work get suspended at once.

>> I sincerely would like to see both the thread and all the people calm
>> down and think more about it, then come around it some time later.
>>
>> I believe everyone who would like to be involved in the implementation
>> wants to see something constructive, not tempered, not trollish, and
>> not rushing. Then I'd like to propose all the IBus related work in
>> wip/input-sources branch of the following components being suspended
>> at once:
>>   gnome-control-center
>>   gnome-shell
>>   gnome-settings-daemon
>>   gsettings-desktop-schemas
>
> Why should the work be suspended? People are working on this, and
> actually making progress. Where are the "better" implementations for
> fcitx integration in GNOME? See below as well.
>

Actually current experience with Fcitx's kimpanel plugin for
gnome-shell is much better than IBus already, the "progress" in those
branches are re-inventing things in IBus to catch up with Fcitx in the
first place.

>> This feature should postponed at least for GNOME 3.6, even if we have
>> agreed on something, six months is too short for producing an almost
>> good release for users according to the current situation.
>>
>> For future discussions, we will try to make GNOME developers
>> understand what input method really is and know about user's
>> requirements. Then we, including GNOME people, IBus developers and
>> Fcitx developers sit down together to figure out what's the right way
>> to do, as re-implementing things is painful at least for users, who
>> really suffer from the result.
>
> The only reason one would make noise in this thread would be if they
> wanted to have either
> 1. fcitx integrated (rather than IBus)
> or
> 2. thought that we should make Input Method frameworks swappable
>

This is not true. The valid one should be something like the following points:

1.We want to have better input experience for input method users of
GNOME, as the already integrated XKB stuff.

2.Forcibly choose between IBus and Fcitx is not a good idea because
most people around still doesn't have the concept of what is IMF and
why foo can be better than bar.

3.Whether it will be a hard dependency is subject to discussion among
related developers, and it is very likely to be not necessary if you
understand the current design of Fcitx.

4.If it is feasible to not hardcode, why do that? Having a recommended
implementation in GNOME is something good, but only hardcode when
necessary and being agreed by related people.

5.GNOME need listen to CJK developers before trying to assume things on IMF.

> 2. isn't an option, as already discussed. For 1., we should in fact
> merge the IBus support as soon as possible, and have fcitx developers
> show us how they can do the integration better. A lot of the code should
> be reusable, and you can show how much more awesome and complete your
> favourite IMF is.
>
> Cheers
>

See above. It isn't something absolute, so please suspend right now,
listen and discuss first.

--
Regards,
Aron Xu