New InputMethod api for Views.

views/ime/input_method.h

+// 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.
+
+#ifndef VIEWS_IME_INPUT_METHOD_H_
+#define VIEWS_IME_INPUT_METHOD_H_
+#pragma once
+
+#include <string>
+
+#include "base/basictypes.h"
+#include "base/i18n/rtl.h"
+
+namespace views {
+
+namespace internal {
+class InputMethodDelegate;
+}  // namespace internal
+
+class KeyEvent;
+class View;
+class Widget;
+
+// An interface implemented by an object that encapsulates a native input method
+// service provided by the underlying operation system.
+// Because on most systems, the system input method service is bound to
+// individual native window. On Windows, its HWND, on Linux/Gtk, its GdkWindow.
+// And in Views control system, only the top-level NativeWidget has a native
+// window that can get keyboard focus. So this API is designed to be bound to
+// the top-level NativeWidget.
+class InputMethod {
+ public:
+  virtual ~InputMethod() {}
+
+  // Sets the delegate used by this InputMethod instance. It should only be
+  // called by the internal NativeWidget or testing code.
+  virtual void set_delegate(internal::InputMethodDelegate* delegate) = 0;
+
+  // Initialize the InputMethod object and attach it to the given |widget|.
+  // The |widget| must already be initialized.
+  virtual void Init(Widget* widget) = 0;
+
+  // Called when the top-level NativeWidget gets keyboard focus. It should only
+  // be called by the top-level NativeWidget which owns this InputMethod
+  // instance.
+  virtual void OnFocusIn() = 0;
+
+  // Called when the top-level NativeWidget loses keyboard focus. It should only
+  // be called by the top-level NativeWidget which owns this InputMethod
+  // instance.
+  virtual void OnFocusOut() = 0;

[Peng, 2011/03/29 19:12:19]

It is better to add some API for browser to trace InputClient focus. So that
browser could use it for controlling virtual keyboard and etc.
Like:

void AddInputMethodFocusListener(Listener *listener);

[James Su, 2011/03/29 19:39:15]

I think it may not be necessary to add such thing here. Because it's not a
common feature for all platforms.

Instead, we can do following things:
1. In code for handling/dispatching touch events, after handling a touch event,
the focused view can be checked explicitly to see if it supports text input.
Then we can popup/hide virtual keyboard accordingly.
2. Encapsulate everything inside the actual InputMethod implementation, which
should know better about how to do it.

And if we really need such thing, I think we can just add it to the Delegate
interface.

[Peng, 2011/03/29 19:50:47]

Your suggestion can work. But it is not idea solution. That need input Browser
UI code understand the detail of InputMethod implementation.

It will be more convenient if the Listener can receive two arguments (InputMehod
*im, InputClient *ic).

On 2011/03/29 19:39:15, James Su wrote:

[James Su, 2011/03/29 22:32:38]

Let's add it later when we figure out the actual way for supporting virtual
keyboard. I still believe such thing should be part of the actual InputMethod
implementation.

On 2011/03/29 19:50:47, Peng wrote:

[Peng, 2011/03/29 22:47:05]

Do you mean we should let class InputMethodIBus control virtual keyboard
directly? 

On 2011/03/29 22:32:38, James Su wrote:

[James Su, 2011/03/29 23:13:14]

It depends on how it's implemented in InputMethodIBus. It may or may not be
direct control. No matter how we implement InputMethodIBus, virtual keyboards
and input methods should be managed in the same way. We can discuss it
separately.

[Peng, 2011/03/30 21:32:37]

I think it is better to have a reasonable idea to support it, before checking
this CL.

For me, it is not reasonable to let InputMethodIBus to control Virtual keyboard
directly. Because InputMethodIBus is in views/. And virtual keyboard is a chrome
extension. It is not a good idea to let views depend on chrome browser code.


On 2011/03/29 23:13:14, James Su wrote:

[James Su, 2011/03/30 21:44:00]

I didn't say to let InputMethodIBus to control virtual keyboards directly.
Virtual keyboards should be controlled directly by ibus itself through the
extension API for virtual keyboards and input methods. That part is out of this
CL's scope.

But anyway, we can always improve this API incrementally according to our future
requirements. So let's keep it as it for now, and move on to other part.

+
+  // Dispatch a key event to the input method. The key event will be dispatched
+  // back to the caller via InputMethodDelegate::DispatchKeyEventPostIME(), once
+  // it's processed by the input method. It should only be called by the
+  // top-level NativeWidget which owns this InputMethod instance, or other
+  // related platform dependent code, such as a message dispatcher.
+  virtual void DispatchKeyEvent(const KeyEvent& key) = 0;
+
+  // Called by the focused |view| whenever its text input type is changed.
+  // Before calling this method, the focused |view| must confirm or clear
+  // existing composition text and call InputMethod::CancelComposition() when
+  // necessary. Otherwise unexpected behavior may happen.
+  virtual void OnTextInputTypeChanged(View* view) = 0;
+
+  // Called by the focused |view| whenever its caret bounds is changed.
+  virtual void OnCaretBoundsChanged(View* view) = 0;
+
+  // Called by the focused |view| to ask the input method cancel the ongoing
+  // composition session.
+  virtual void CancelComposition(View* view) = 0;
+
+  // Returns the locale of current keyboard layout or input method, as a BCP-47
+  // tag, or an empty string if the input method cannot provide it.
+  virtual std::string GetInputLocale() = 0;
+
+  // Returns the text direction of current keyboard layout or input method, or
+  // base::i18n::UNKNOWN_DIRECTION if the input method cannot provide it.
+  virtual base::i18n::TextDirection GetInputTextDirection() = 0;
+
+  // Checks if the input method is active, i.e. if it's ready for processing
+  // keyboard event and generate composition or text result.
+  // If the input method is inactive, then it's not necessary to inform it the
+  // changes of caret bounds and text input type.
+  // Note: character results may still be generated and sent to the text input
+  // client by calling TextInputClient::InsertChar(), even if the input method
+  // is not active.
+  virtual bool IsActive() = 0;
+
+  // TODO(suzhe): Support mouse/touch event.

[Peng, 2011/03/29 19:12:19]

It is better to have a static helper function like:

static InputMethod *FocusedInputMetthod();
or
static InputClient *FocusedInputClient();

We may need it for touchui. we could use it to talk with focused view.

[James Su, 2011/03/29 19:39:15]

Good point. I'll add some helper methods.

+};
+
+}  // namespace views
+
+#endif  // VIEWS_IME_INPUT_METHOD_H_