Integrate the new input method API for Views into Chromium.

chrome/browser/chromeos/login/screen_locker.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/chromeos/login/screen_locker.h"
 
 #include <X11/extensions/XTest.h>
 #include <X11/keysym.h>
 #include <gdk/gdkkeysyms.h>
 #include <gdk/gdkx.h>
@@ skipping 675 matching lines @@
 void ScreenLocker::Init() {
   authenticator_ = LoginUtils::Get()->CreateAuthenticator(this);
 
   gfx::Point left_top(1, 1);
   gfx::Rect init_bounds(views::Screen::GetMonitorAreaNearestPoint(left_top));
 
   LockWindow* lock_window = new LockWindow();
   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);
 
   // GTK does not like zero width/height.
   if (!unlock_on_input_) {
     screen_lock_view_ = new ScreenLockView(this);
     screen_lock_view_->Init();
     screen_lock_view_->SetEnabled(false);
     screen_lock_view_->StartThrobber();
   } else {
@@ skipping 442 matching lines @@
 
 bool ScreenLocker::AcceleratorPressed(const views::Accelerator& accelerator) {
   if (!background_view_->IsScreenSaverVisible()) {
     StartScreenSaver();
     return true;
   }
   return false;
 }
 
 }  // namespace chromeos