Re: 3.6 Feature: IBus/XKB integration

[Marguerite Su <i marguerite su>]

On Sun, May 13, 2012 at 10:19 AM, Benjamin Otte <otte gnome org> wrote:
> Marguerite Su <i <at> marguerite.su> writes:
>
>> what if after one or two years, a brand-new IM comes.
>>
>> then you guys will remove all ibus codes and start what you do today again?
>>
>> and after another one or two years, again again.
>>
>> then it becomes you guys' life-time career to fix bugs and reinvent the wheels.
>>
>
> Yes, that is exactly what I do.
> In fact, I enjoy it a lot to port to a new and better solution and making sure
> that solution works really well [1] than trying to be compatible with lots of
> different options.
>

Hi, Ben,

At first I want to be clear, as culture gap exists,

I didn't mean to laugh at you or something bad (to all developers, or
I should be kicked from this thread). and I'm not angry or
mad(myself). all I care is the future of IM in GNOME.

my point is,

you can work on an universal protocol or framework and solely maintain
it or improve it to adapt to and let new members in. as I know, it's
simple and easy for you than to work on specific IMs. maybe just a few
lines' change will help a lot, but if you turn to IM, you'll get your
hands dirty and surely can't do it well. (even IBus developers
themselves can't, not to say, GNOME developer)

because you think different with end users. a best IM developer must
be its heavy user. I do trust you will use IBus or something to input
English since you want to know if it's in good state with GNOME. but
will you write in CJK? based on your family name,  you won't. Can you
read bug reports in CJK? you won't.

then you're not a best listener. because IM is for CJK. I can't
imagine an English man needs something between him and his keyboard.

I'd like to hear you say the word "compatible". but why "a" solution?

it's more compatible to provide an universal standard than a solution.
the solution might be outdated later, but standard lives.

And you at least see two teams, IBus and Fcitx, are showing their
kindness to make such standard. (IBus people must want a standard too,
or they'll not even cooperate with you. because every father thought
his babe unique.) so why not bring the three sides in together and
talk.

and from your words, I saw a sad trend that upstream developers are
becoming further away from end users. like living in a ship in the sea
to invent housing building technologies, but they don't even care if
people on land still live in house or if the land still exists.

> If one chooses a single target, one has a lot of advantages:
> - Tight integration is possible.

there're many reasons why tight integration is not acceptable to end
users. like I said, what you think doesn't matter.

> - One can rely on certain behaviors of that target

what if the one you mentioned here does not even rely on that target?

"he can" doesn't mean "he has to".

> - New features can be used immediately

then what do you do to other features provides by others?

to compare features, fcitx or any new IM certainly has more user
experience features than IBus. by embracing "New features", you may
reject many more. please keep in mind that they might be released just
after the day you release your "tight integration".

> - We have a single point of contact for discussions about the future
>

then you reject more contacts at the same time. you're closing
yourself in a dark room.

if the project you contact to dies, you may hardly know there're
others in the world.

the future is diversified and has many possibilities.

one or two persons can't even tell the future, not to say, judge.

> Of course, this also requires a lot of things working well between that single
> target and GNOME:
> - A target that is working well for all use cases

then who will judge "working well", you? you're not an IM user; IBus
team? they definitely love IBus and prefer it.

the users will. I say users, including those whose want GNOME but
don't want the target you provide.

> - A willingness from both sides to cooperate

fcitx developers are not fighting with you. they want to sit down and
talk about collaboration. so why not give them a chance like you gave
to IBus team?

> - A working relationship between the involved people
>

like I and others in this thread said, they have been trying to build
such connection for a enough long time. the "GTK_IM_MODULE" thing, but
the willingness was ignored.

and you said you found working relationship. but can you say you
didn't receive such willingness. nope.

> You can find a lot of examples where this works very well [2] and of course I
> can also come up with some where it didn't work and we needed to change things
> and start over. [3]
>
> So what I think we as the GNOME project want to see happen is that we find a
> team that is excited to work with us on improving input methods in GNOME
> applications. [4] If that project is called IBus, fcitx, XIM or is something
> that is redone from scratch, I don't know. I also don't know if the project of
> choice will be ready as-is or will need significant improvements. I also don't
> consider myself the person to decide it.
>

it's also fcitx developers' pleasure to work with your team. but fcitx
developers don't want to eliminate the possibility for IBus developers
to join in.

> But I am very convinced about two things:
> We want a single solution.

yes. I know what you want.

but what you want is not the thing users want too. nor IM developers.

then do you still want it?

if so, users will certainly leave, a lot many.

then who are you developing the project for? youself?

then I suggest you to choose openbox or something, because GNOME is
not the type that one can solely on his own.

> And we want you to be happy with it.
>

Yes, and all I want is let us all parties sit down together and make
the world a better place .

> Benjamin
>
>
> 1: If you want references, look at the GTK Cairo work I did. And that is now
> superseded by Clutter. You can also look at the transition from X11 to Wayland
> for an example of that. I'm pretty sure we will make a rather seamless
> transition at one point there and not try to support both.

but IM is not the low-level case that can apply to all users.

an English person and an Chinese person both need
GTK-Cairo/X11/Clutter, but not both of them need an IM.

> 2: Tight coupling of GNOME with X11, NetworkManager, WebKit or Pulseaudio
> improved things a lot. At least that's my opinion.

it's because you can judge which ones are better choices in these
cases. it's low-level tech away from users. they don't even care about
them. but IM, users really do care and not the one you can judge.

because you can't, so you have to implement all of them. that's the
right thing to do. but a lot of hard work. that's why we users want to
free your hands by introducing an universal standard.

> 3: The big example of a failed relationship is with Mozilla. It failed once
> already (the Epiphany guys with GtkMozEmbed - they started over with WebKit) and
> the Javascript situation (gjs is based on Mozilla's SpiderMonkey) isn't very
> nice either. Another example that never worked out is spell-checking. Enchant
> was never really integrated into GTK and that is why you can't spell-check
> normal text entries...

Mozilla is the bad experience we shared together. every single CJK IM
user and developer suffered once or twice with it. why not three time
or four times? because we left it. what's worse, Opera.

see, spell-checking is another common misunderstanding you holds.

CJK don't need spell-check, the spell check work is done by IM. like
you type "abcd", IM will return you "我(me)", but if you type it wrong
"acbd", IM will return you "你(you)". but you want to  spell check them
that are already on screen? not even possible. because like the word
"侬", can represent either me or you.

> 4: As a GTK maintainer, I'm not happy about IM modules as they generally contain
> very ugly and often just look plain bad when they try to pop up their own little
> X windows in all the wrong places. I'd also be very happy if I could show more
> useful information than an underlined pre-edit string.
>

oh no, please never do that, you'll make yourself world famous of doing that.

like every CJK said on Twitter or forums, "the so-called foreigners
will never truly know what an IM is.", this time they will all call
you stupid directly.

because those windows are the common design. everyone needs it.

if it has to be changed, it's already done.

if it needs to be changed, it can't be changed by a person who don't
understand what it is ,what it's like and what it's for.

> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

PS: one thing kept bothering me is:

why manual selection?

suppose:

this time you select IBus, you make fcitx sad; next time you select
Fcitx, you make IBus sad...

this cycle will come to an dead end, which is, you make all IM sad.
then which one will cooperate with you again? (because there're few IM
developers than GNOME developers, they develop slow than the speed you
select)

but if you keep IBus next time, and just let Fcitx in.

there'll be another cycle, at last you have all the IMs. then it
returns to the beginning: why not develop an universal framework to
contain them all?

it's basic math. I think you must know it.

Hope it helps

Marguerite.