[linux/aura] Supports IBus in async mode.

[linux/aura] Supports IBus in async mode.

ibus-gtk in async mode processes key events asynchronously and sometimes pushes key events back to the GDK event queue.  So we need to pull those pushed-back GDK events from the queue in order to support ibus-gtk in async mode.

This CL pulls GDK events from the GDK event queue and translate them into X events and puts them back to the X event queue, so as if ibus-gtk puts those key events back to X event queue instead of GDK event queue.

The reason that we'd like to support ibus-gtk in async mode is that ibus-hangul doesn't work well with ibus-gtk sync mode.  See Issue 354495 for details.

BUG=354495
TEST=Done manualy.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=262352

[Yuki, 2014-04-04 12:11:19]

Hi Elliot,

Could you take a look at this CL?

Although we're not happy to introduce GDK dependency back, this CL fixes the
issue.  I'd like to hear your thoughts about how to fix the issue.

[sadrul, 2014-04-04 12:47:13]

The message-pump should not do any gtk/gdk work. This code should move somewhere
into chrome/browser/ui/libgtk2ui/

[Yuki, 2014-04-04 15:13:54]

On 2014/04/04 12:47:13, sadrul wrote:
> The message-pump should not do any gtk/gdk work. This code should move
somewhere
> into chrome/browser/ui/libgtk2ui/

Okay, let me move it.  Do you guys have any other opinions or concerns to the
approach itself?  I'd like to confirm our approach first.  Are you guys okay as
long as GDK related code lives in chrome/browser/ui/libgtk2ui?

[sadrul-g, 2014-04-04 15:18:59]

On Apr 4, 2014 11:13 AM, <yukishiino@chromium.org> wrote:
>
> On 2014/04/04 12:47:13, sadrul wrote:
>>
>> The message-pump should not do any gtk/gdk work. This code should move
>
> somewhere
>>
>> into chrome/browser/ui/libgtk2ui/
>
>
> Okay, let me move it.  Do you guys have any other opinions or concerns to
the
> approach itself?  I'd like to confirm our approach first.  Are you guys
okay as
> long as GDK related code lives in chrome/browser/ui/libgtk2ui?

Redirecting events from one X display to another feels a bit icky. There is
also a good chance a change that simply redirects all key events is going
to break key event handling in other places where we use gtk widgets (eg
file selection dialogs, print etc)

>
> https://codereview.chromium.org/224723008/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Elliot Glaysher, 2014-04-04 18:00:19]

On 2014/04/04 15:13:54, Yuki wrote:
> On 2014/04/04 12:47:13, sadrul wrote:
> > The message-pump should not do any gtk/gdk work. This code should move
> somewhere
> > into chrome/browser/ui/libgtk2ui/
> 
> Okay, let me move it.  Do you guys have any other opinions or concerns to the
> approach itself?  I'd like to confirm our approach first.  Are you guys okay
as
> long as GDK related code lives in chrome/browser/ui/libgtk2ui?

GDK/GTK code shouldn't live outside of c/b/u/libgtk2ui/. I'm not enough of a
domain expert to comment on the rest of the approach and defer to sadrul.

[Yuki, 2014-04-07 09:43:30]

Updated the code.

I've moved GDK/GTK dependent code into c/b/ui/libgtk2ui.

Sadrul was right.  My first patch broke GTK widgets (file selection and print
dialogs).  I changed the code so it keeps running gtk_main_do_event() even when
we put the key events to the X event queue.

I know that this CL is still very hacky and you'd feel icky, but this seems the
only solution for us in short term.

[Elliot Glaysher, 2014-04-07 18:01:09]

On 2014/04/07 09:43:30, Yuki wrote:
> Updated the code.
> 
> I've moved GDK/GTK dependent code into c/b/ui/libgtk2ui.
> 
> Sadrul was right.  My first patch broke GTK widgets (file selection and print
> dialogs).  I changed the code so it keeps running gtk_main_do_event() even
when
> we put the key events to the X event queue.
> 
> I know that this CL is still very hacky and you'd feel icky, but this seems
the
> only solution for us in short term.

This is fairly hacky, but given the constraints, I'm not sure how I'd make it
any cleaner. It's fairly well encapsulated, too. I also like how this gets rid
of initialization code in ui/base/ime/.

lgtm

[Yuki, 2014-04-08 01:25:31]

Sadrul@, could you take another look at this CL?

[sadrul, 2014-04-08 03:02:43]

lgtm

[Yuki, 2014-04-08 03:11:56]

The CQ bit was checked by yukishiino@chromium.org

[commit-bot: I haz the power, 2014-04-08 03:12:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yukishiino@chromium.org/224723008/20001

[commit-bot: I haz the power, 2014-04-08 08:43:25]

Change committed as 262352