Integrating GtkIMContext into the RenderWidgetHostViewGtk class (Take 2)....

Integrating GtkIMContext into the RenderWidgetHostViewGtk class (Take 2).

This change is an updated version of <http://codereview.chromium.org/126118>; that I reverted because of issue 15024 <http://crbug.com/15024>;. This issue 15024 is caused by my bonehead mistake that I forgot handling the case that gtk_im_context_filter_keypress() returns false. (The GtkIMContext usually returns false when we type control keys, such as return, page up, page down, etc.) To handle this case, this change added code that manually creates a Char
event and send it to the renderer in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent(). Except this code, it is exactly the same as <http://codereview.chromium.org/126118>;.

Unfortunately, this change still uses std::wstring, I'm going to send another change which replace std::wstring with string16.

(The following message is copied from <http://codereview.chromium.org/126118>.)

This change implements signal handers of the GtkIMContext object to support IMEs anddead-keys. Also, to improve compatibility with Windows Chrome, this changeemulates IPC messages sent on Windows when we input characters and fixes
Issue13604 as well as Issue 10953 and 11226. Even though I notice we need more workfor fixing edge cases (e.g. disabling IMEs on a password input) on Linux, Ithink this is the good starting point. (Supporting edge-cases requirescomplicated code and it makes hard to review.)

BUG=10953
"IME support"
BUG=11226
"Dead keys and accents input not working"
BUG=13604
"Hotkeys not working in non-us keyboard layout"
BUG=13711
"Alt-D does not work when in editbox"
TEST=Open a web page which contains an <input> form, type a '[{' key and an 'A' key on a Canadian-French keyboard, and see a Latin character "U+00E2" is displayed in the <input> form.
TEST=Open a web page which contains an <input> form, enable an Chinese Pinyin IME, type a 'W' key, type an 'O' key, and see a Chinese character is displayed in the <input> form.
TEST=Change the keyboard layout to Hebrew (or Russian), open a web page which contains an <input> form, input some characters in the <input> form, type control+a, and see the text in the <input> form is selected.
TEST=Open a web page which contains a <textarea> form, type a return key, and see a new line is inserted.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=19238

[Hironori Bono, 2009-06-23 15:18:03]

I'm very sorry for bothering you with my stupid changes.
I confirmed this updated change worked without side-effects noted in issue 15024
<http://crbug.com/15024>.
Would it be possible to review this change again?

[Evan Martin, 2009-06-23 15:20:27]

On 2009/06/23 15:18:03, hbono wrote:
> I'm very sorry for bothering you with my stupid changes.

This is really hard to get right (we also didn't have enter working in the
initial keyboard implementation!).  So no apologies are necessary.

What is different about this change from the previous one?

[Evan Martin, 2009-06-23 15:22:32]

oh, i see, you added to the review desc.  looking...

[Evan Martin, 2009-06-23 15:23:51]

LGTM

Can you verify that page up / page down as well as some hotkeys (ctl-T while the
content is focused, copy and paste, ctl-shift-tab to switch tabs) work?

[Evan Stade, 2009-06-23 19:53:50]

I agree, don't go so hard on yourself. Regressions certainly aren't desirable
but they are a natural part of progress. LGTM2. If you want a list of hotkeys
for testing you can look in BrowserWindowGtk at the kAcceleratorMap struct.

[Hironori Bono, 2009-06-24 11:17:45]

Thank you for your reviews and  encouraging comments.
After I sent my previous message, I noticed some IME send control characters in
the RenderWidgetHostViewGtkWidget::InputMethodCommit() function and this causes
a crash in TabContentsViewGtk::HandleKeyboardEvent(). I updated my change to fix
this problem and prevent sending Char events which contains non-printable
characters in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent().
Since we have been testing Linux Chromium containing this change with my friends
today, I'm going to commit this change tomorrow if this updated one also looks
good for you and we don't notice any more serious regressions.

[Evan Stade, 2009-06-24 18:53:49]

lg once more :)

http://codereview.chromium.org/147011/diff/1009/31
File chrome/browser/tab_contents/tab_contents_view_gtk.cc (right):

http://codereview.chromium.org/147011/diff/1009/31#newcode316
Line 316: if (event.type == WebKit::WebInputEvent::Char)
it seems like it would be more direct if you made this check for event.os_event,
but it's not a big deal