Integrate the new input method API for Views into Chromium.

chrome/browser/chromeos/login/screen_locker.cc

Index: chrome/browser/chromeos/login/screen_locker.cc
diff --git a/chrome/browser/chromeos/login/screen_locker.cc b/chrome/browser/chromeos/login/screen_locker.cc
index 9c0530e89a68d068db516b06bb2e267c3869a1ea..c36bdd87a7990e0a62f9fb69bdbfeb8c6a323fcb 100644
--- a/chrome/browser/chromeos/login/screen_locker.cc
+++ b/chrome/browser/chromeos/login/screen_locker.cc
@@ -693,6 +693,11 @@ void ScreenLocker::Init() {
   lock_window_ = lock_window;
   lock_window_->Init(NULL, init_bounds);
 
+  // Disables input method explicitly, because:
+  // 1. Input method only works when top-level Widget gets keyboard focus.
+  // 2. Screen Locker shouldn't allow the user to use input method.
+  lock_window_->native_widget()->ReplaceInputMethod(NULL);

[oshima, 2011/03/24 22:58:47]

Two q:
1) I assume we'll not use new API for existing gtk implementation, correct?

2) User can use different keyboard layout, and can use some control key to
switch keyboard layout. I believe it's using some ibus stuff to control this
behavior. I assume your change won't break this behavior on chromeos, correct?

[James Su, 2011/03/25 05:57:21]

Yes, I guess so. As long as we are not going to use TextfieldViews and
RenderWidgetHostViewViews. So actually it's pretty safe to disable the
corresponding code in WidgetGtk for ChromeOS. I'll change it asap.
Current chromeos uses a very hacky approach (gtk key snooper) to intercept key
events and perform such actions before dispatching the events to chrome.

We need to get rid of this ugly thing in TouchUI and do it in InputMethodIBus
object.

You know, the whole input method/keyboard layout solution in current chromeos is
actually very hacky, caused by limited design and feature of ibus. Sooner or
later we need to rework all of these parts.

TouchUI is a good point for us to rethink everything. But unfortunately, both
ChromeOS Japan team and Peng insist to believe that ibus is good enough and can
be improved to support everything we need. I tried to persuade them but failed.
That's why this new abstract input method API is important for chrome, so that
the chrome code won't be affected when we need to switch underlying input method
framework.

[oshima, 2011/03/25 17:31:25]

I think new API is needed regardless. Improvement is always good, but you need
to prove it, especially when there is working solution. And when you do, it's
important to provide smooth transition path. It should be able to switch between
two implementations easily without hassle.

+
   g_signal_connect(lock_window_->GetNativeView(), "client-event",
                    G_CALLBACK(OnClientEventThunk), this);