Re: Some points about IM integration

[Aron Xu <aronxu gnome org>]

Hi Owen,

I'm sorry to see that you are trying to drag us back to discuss about
"which IMF is better", which is very likely to start a flame war on
the list.

Please excuse me if some of my replies are _tooooooo_ direct and
_seems_ to be unfriendly, the idea behind is that I *sincerely* wish
to lead both sides to a happy result.

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.
>

No. Given no choice is something wrong. GNOME3 is advertised to be
design driven, but have you heard about some rumors like this one:

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."

So, let's concentrate on the integration of IMF, and surely yes, we
all know that integration can possibly bring users a better
experience. But this will work if and *only* if we don't push people
very hard to work in a way they don't think feasible. Given that GNOME
cannot reinvent another IMF definitely, and given that GNOME is
lacking specialized people on this particular item, please at least
follow their advice and don't try to push them to fit schedule.

Just emphasizing the good side of doing such will very probably bring
a half-baked broken system to users. And I want to emphasize again
that IMF is very important to their users, much more important than
any other visible components including but not limited to music
players, editors, etc. Because when the input system isn't working
well or become confusing, the user is forced to stop using the whole
environment or he/she cannot be producible. Think about your keyboard
is not working properly and you are stopped away from inputting
anything to Web, Gedit and any other applications, can you continue
your work with it?

So _don't be hurry_, _don't rush_. Let's sit down for a cup of tea and
plan it _much more carefully_.

> 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.
>

Distributions are already trying their best to cook out the best
recipe for their target users, and all of these efforts are based on
the fact that the software they use is an open system with a free
license.

But GNOME is on its way of being a closed system, though it comes with
a free and open source license, it has been actively taking away users
and developers' choices in the _name_ of experience. What free
software users are expecting is an open system with a free license,
and I doubt what's for a closed system with a free license. Is this
like using free software to build an DRM enabled system? Anyway users
are not able to change the presets anymore because they are
deliberately made to be deep dependency, in the name of "we can only
concentrate on foo, so bar is totally ignored, use foo or go away".

> 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.
>

Then please raise the proposal about GNOME OS again, so all others can
stop making GNOME based distributions because all others are just
making "a working system" but GNOME OS will possibly be "a fully
working one". The difference in the given wording is obvious, I think.

> 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.
>

Why GNOME can't? Why just stop other distributions to make a best
recipe for their users? This means all GNOME users and distributors
must accept ALL or NOTHING. This reminds something that truly bad in
our mind, and think about who is pushing such changes.

Just _thinking_ something is good is not the right approach, because
GNOME is not a lord project that everyone must follow. Users of these
languages are using all the different input method frameworks and
engines for years, and GNOME is not able to change the fact
_instantly_.

So, again, _don't be hurry_, _don't rush_.

> 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!
>

Sure because we love the project. Even here we have some hardcore KDE
users/developers (not me) in the thread, we are so sure that we don't
want CJK users suffer from a decision made by a small group of people
who don't even have required concepts in their minds, and we want to
see GNOME, a great free software project, isn't choosing a wrong way
of doing things. We want to alarm that CJK inputting method system is
complex and the situation is complicated.

If we truly wants to work on sorting some mess out, then fixing bugs
in GTK+ first is a very appealing start.

> 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.
>

All of our CJK developers are surely know what the discussion is
about, but the situations for IMF aren't like Jackd and PulseAudio
which has clearly different target users.

> 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*.
>

CJK developers are the backbone of the input system about complex
characters, so we believe we're much more clear about the problem -
just like we know less about XKB than their users.

> 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.
>

Yes and no, because if we really want a single input method framework,
then we should make it freedesktop.org standard or at least X.org,
just like what have happened with XKB[1]. Making GNOME specific
assessment will eventually break more and more other things and make
GNOME a more closed system.

[1]http://www.x.org/wiki/XKB

> 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.
>

And it's pretty much essential to say again that  _don't be hurry_,
_don't rush_.

Input method frameworks are using up all kinds of shortcuts and users
are having their all kinds of preferences, so making assumptions on
shortcuts without asking the real users is certainly bad.

> 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.
>

True. That is a proposal to try to make both side happy - and I still
see it's the only way if we are rushing - though there are real
difficulties.

> 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.
>

Not for now, not so urgent, surely.

> 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

The fact behind GNOME and IBus's collaboration is because Redhat.
Because currently IBus is maintained by the original author and
several RH people (the latter are doing more in recent time), so
communication can happen with RH designers and developers (who are
pushing such an idea) when outsiders don't knowing anything. If not
so, why the collaboration happened before now?

--
Regards,
Aron Xu