Re: Some points about IM integration

[Marguerite Su <i marguerite su>]

On Tue, May 15, 2012 at 7:27 AM, Owen Taylor <otaylor redhat com> wrote:
> In general, choice of input method framework is not a goal in itself.
> If we choose a single input method framework to integrate with GNOME -
> that doesn't make GNOME like proprietary software from Apple and Microsoft,
> because GNOME will still be 100% Free Software, and will still be developed
> in the open by the GNOME community.
>
> GNOME doesn't want to work well just for tweakers and enthusiasts - it's
> very important to the project that GNOME works well for all users without
> tweaking. We want to give the choice of using Free Software to
> everybody - this is a much more fundamental form of choice than giving a small
> group of users the ability to swap out a different input method framework
> underneath GNOME.
>

no offense, but if Chinese or CJK Community is "a small group"(I think
I've already be clear about what CJK users are doing today. they'are
the nowadays tweakers you called. why? because you didn't ship what
they want. you know, IM is the most famous workaround in i18n world),
GNOME Asia can be shutdown.

so is Chinese or CJK Community "a small group" or "second class"? say
that in public in Hong Kong.

so do not make any hypothesis you don't even know about.

I've heard enough of this and feel great disrespect.

assume: if "world factory" think, "oh, english users has little
feedback in Chinese. so they're a small group". then ship any kind of
clothes, shoes they like to Europe market. will you buy it?
absolutely and apparently no.

then that's the case GNOME will face.

I've also heard enough of "oh, then the only solution is to drop
GNOME" in Chinese Community about this affair.

I'm okay about it. they're users, I as a packager can't force they
choose what they like.

and today they still, although the choice range is becoming narrower
but still, have choices. KDE/xfce.

I'm okay about it. no matter what they will use, they're still my
target as a packager.

but can you be okay about it?

can you even dare a little bit to say "CJK is not important"? no.

then pretty much GNOME developers will leave GNOME tomorrow.

that's the worst case we both never want to see it ever happens.

if no users/local developers, who will you develop an IM for?

sorry for my wording, but it really drives me crazy.

I think mutual respect is the basis for multi-culture communication.

> GNOME isn't just a set of parts that a Linux distributor takes and uses
> to create a working system - we also take responsibility for creating
> a fully working system. This means deciding how GNOME interacts with
> system components like sound and networking and printing and when necessary
> enhancing those components to provide the right experience to the user.
>

yes and no. your will is good and respectful.

but have you ever discussed it with downstream distributions?

I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
think on this.

yes, I agree and thanks for, some of GNOME applications are god-like
good, but GNOME itself is not GOD to make decisions for
users/distributions/others.

or maybe tomorrow you would like to say "oh, we should take
responsibility to write a new kernel, we should take responsibility to
reinvent YaST2"? that's what you think arrogantly and will certainly
do if you find upstream doesn't accept you proposal.

"want to take responsibility" is under the hypothesis that "the ones
who nowadays had already taken responsibility want to share." but have
you ever asked?

no. at least Vincent will feel surprised on this.

who will judge "the right experience"? users themselves.

so what if they do not even ever want/like your
over-responsibility-driven product?

that's the case right now.

"oh, we should take responsibility to ship an IM we think users like",
while actually a large  group of its users are using and will use a
totally different tool.

what you think, does not, and will not, even ever matters.

> So we can't leave it up to one Linux distributor to combine GNOME with
> fcitx to make a version of GNOME that works well for zh_CN and another
> Linux distributor to combine GNOME with RIME or hime to make a version
> of GNOME that works well for zh_TW. We want GNOME to, without customization,
> work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.
>

that's what distributions nowadays are doing. and users said, say and
will say, "I like it".

they enjoy this freedom feeling.

"I think tomorrow I will be a millionaire" doesn't make any sense.

do respect reality.

> Of course, it would be a mistake to think that a small group of English
> speaking developers could make GNOME work well in all these languages. That
> would be impossible! But from experience, we know that simply leaving a
> problem like this to external developers and hoping for the best doesn't
> work out well. Instead we need to engage users and developers from these
> language communities into the GNOME development community.
>
> I don't want to minimize how easy that is - I know there are very significant
> barriers of language, timezone, and distance that make this hard. I know
> that bugs get ignored and patches sit around unreviewed. But still,
> active engagement is the only way forward. I think it's absolutely wonderful
> how many people have gotten involved in the current discussion!
>

yes. and you've got all CJK IM developers here. absorb them.

then it'll be a thread technically I can't say any word on.


> We also need to keep in mind that we aren't talking about the choice of input
> method, we are talking about input method *frameworks*. The basics of passing
> events from application to daemon, loading different input method backends,
> handling hotkeys and displaying feedback are going to be very similar for
> all East Asian languages.
>
> Things like displaying feedback may be a little different if we move further
> afield to Thai or Hindi - but still, there is no fundamental reason that they
> need a different *framework*.
>
> Using a single input framework for all GNOME users has many benefits.
> GNOME developers can reproduce bugs that users run into. Bugs only have to
> be fixed once, not in multiple frameworks. We can actually figure out how
> to make input methods work with onscreen keyboards and accessibility. Our
> designers can collaborate on making the configuration dialogs conform to
> GNOME standards.
>
> Finally, using a single input method framework is pretty much essential to
> the goal of allowing users to configure languages at runtime with a nice user
> interface. If language A and language B require different input method
> *frameworks*, there is no way that the user can switch between them with a
> hotkey.
>


> In general, I don't see standardizing D-Bus interfaces so that GNOME can
> work with multiple input method frameworks as being a useful activity.
> If the D-Bus interfaces are carefully maintained and changed only with
> agreement and advanced notice, then they will impede the progress of bug
> fixing and making things better. If the interfaces are not carefully
> maintained, then they aren't standards at all, and users will constantly
> encounter breakage.
>

see, you plan to invent your kernel.

> And in any case, as described above, there has to be *one* framework that
> works as well as we can possibly make it for all users. Multiple partially
> working frameworks are not a substitute.
>
> 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.
>
> - Owen
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list