Short term GNOME 3 plan for input methods?

[Owen Taylor <otaylor redhat com>]

So, as we come down to the release, one thing that's been hanging around
and been ignored is what we are doing about input methods. How do you
input Chinese, or Hindi into GNOME 3?

We have a pretty clear idea of how it's supposed to work:

https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage

This involves tight integration with both the input method framework and
XKB to blur the lines between them for the user.

We have a decent XKB-only keyboard indicator in GNOME Shell currently:

 http://fishsoup.net/images/xkb-indicator.png

But the tight integration of IBus into that is not going to happen for
3.0. Still, for GNOME 3.0 it would be good if we had *some* story about
how you use it together with input methods. We could have a long
discussion of different input method frameworks, but I'm going to cut to
the chase and say that the one that is most actively developed and GNOME
aligned at the moment is IBus, and we should concentrate on making
GNOME 3 work really well with that one framework instead of trying to
make things configurable 8-ways.

Right now, if you use current IBus, its status icon appears hidden in
the message tray, which doesn't make a lot of sense. The message
tray isn't designed for tasks like indicating and switching input
language.

 http://fishsoup.net/images/ibus-status-indicator.png

There has been work going on by Takao Fujiwara to make IBus integrate
with the shell. He's put a lot of work into it, and it's basically
functional at this point:

 http://fishsoup.net/images/ibus-indicator.png

but there's obviously a big gap between where that is now, and where we
want to be from a design perspective. I've put a somewhat detailed
report of my testing at:

 https://bugzilla.gnome.org/show_bug.cgi?id=641531#c19

Here's my basic idea of what we might be able to do for GNOME 3:

 * We don't want either the old indicator or the new indicator showing
   by default for locales like English. It doesn't make sense to have
   an icon with "No input method/Preferences/About" just sitting there.

 * We should devise some way that we can preconfigure IBus with an
   appropriate input method for the locale for common locales
   (zh/hi/ko/ja at the minimum) that do require an input method.

   This may be something that's done more at the distro building
   level than at the GNOME level, but we need recommendations
   for the distros of how it should be set up.

 * There should be some way to get IBus configured to run for other
   locales. This could be a) just something in the release notes
   that you run from a terminal 
   b) a checkbox in the "Region & Languages" panel.

 * If we can fix up the immediate issues with the JS indicator in
   the next few days, we should land it. Otherwise, we should whitelist
   the old indicator and get it to appear in the top panel. It's
   frustrating to do that just as we are finally getting rid of the
   networking icon, but I think it's less weird than having a vital
   system function in the message tray. (Especially if it shows up
   as 'main.py'!)

   There are ~20 translatable strings in the JS indicator, about half of
   which go away if my suggestion to remove the About dialogs is
   accepted.

So, at this point, you (as a member of the release team) are probably
saying "WAIT! IBus isn't an approved external dependency, you want to
add a dependency weeks before the release???" To be clear, all code
added to gnome-shell would be completely optional. If you don't have
IBus, you don't get an indicator from what we ship. If a distro has some
other means to input other languages, then it's free to patch up GNOME
Shell to make it work as well as possible. (Whitelisting status icons
to appear in the system status area is a small patch.)

My plan is to continue investigating this over the next few days to see
if I can figure out a plan for the configuration issue, and see if 
we can fix up some of the immediate issues with the JS indicator to the
point where I'd be comfortable with it going in as an alternative to the
old indicator.

I'll report back later in this week about where we are with that.

- Owen