Bug 810211

gdk_event_handler_set() calls the callback for the keybinding only which is assigned in XIGrabKeycode() in XI2.
So I think if you press ctrl+a, the callback is not called and probably it might be hard to fix this.

Created attachment 583209 [details]
Patch1 for upstream

Created attachment 583210 [details]
Patch2 for customizable Control+space

For ibus-gjs:
https://github.com/fujiwarat/ibus-gjs/commit/58753582f50a030f57b34e6f06071c3a132afe59

This is an intended behavior. It is like window switcher dialog of gnome3:
(After Alt+Tab, without release Alt key, user may press arrow keys for navigating focus between windows.)
And in future, we can also add following logic:

1. Ctrl + Space (to fire the ime switch window)
2. Letter to (navigate focus between IME which names start with letter user pressed and etc)
3. Release Ctrl, do the real IME switch.

The requirements is different between the focus change and the IME change. no one expects to have any operations on originally-focused window with/during/after the focus change anymore. but not on the IME change. having same behavior regardless of it makes no sense at all.

This is actually a bigger regression and affects the usability. it's not completely accepted.

For the future plan, I'm not quite sure what you are trying to address but I don't think it's worth implementing by giving up the usability and the existing features. I'm also wondering how often one changes among IMEs. in most cases, they should have only two (the keyboard layout thing and IME for their native language).

(In reply to comment #5)
> This is an intended behavior. It is like window switcher dialog of gnome3:

I think yourself only intend it.
This is a regression bug and we believe this should be fixed.

You don't have to try gnome-shell. The behavior should be owned by ibus-gjs.
I think the GTK based ibus should have the similar behavior with metacity.

When I implemented this logic in ibus, I followed behavior of gnome2 (compiz WM) and gnome3 Window switcher dialog (I din't try KDE).

Anyway I respect your decision. Just want to let your guys know why I did it. And I also think it is hard to fix, because the following key events are already consumed by IME switcher dialog. You have to do some dirty hacks to change current behavior.

Thanks for the comment. what I was saying on this is,  no matter what desktops you were referring to implement this feature, having same behavior with the window switcher that is supposed to change the focus is wrong for IME switch.

(In reply to comment #5)
> 1. Ctrl + Space (to fire the ime switch window)
> 2. Letter to (navigate focus between IME which names start with letter user
> pressed and etc)
> 3. Release Ctrl, do the real IME switch.

Probably I think it's an idea to replace this with engine hotkeys or Contrl+[1, 2, 3....]

(In reply to comment #8)
> When I implemented this logic in ibus, I followed behavior of gnome2 (compiz
> WM) and gnome3 Window switcher dialog (I din't try KDE).

compiz-gnome is no longer available in Fedora 17.

> Anyway I respect your decision. Just want to let your guys know why I did it.
> And I also think it is hard to fix, because the following key events are
> already consumed by IME switcher dialog. You have to do some dirty hacks to
> change current behavior.

I already provide the patch and it's enough for me.

ibus-1.4.99.20120428-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/ibus-1.4.99.20120428-2.fc17

Package ibus-1.4.99.20120428-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-1.4.99.20120428-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8084/ibus-1.4.99.20120428-2.fc17
then log in and leave karma (feedback).

Is it possible to resend the key event after canceling the switcher? I think the updates improves this issue a bit but there are still a regression.

(In reply to comment #13)
> Is it possible to resend the key event after canceling the switcher? I think
> the updates improves this issue a bit but there are still a regression.

I thought we agreed it's no problem whether the key event cancel the switcher or it's sent to the client applications.

I think resending the event won't work since ibus panel works outside the applications and the GdkEvent does not include the focused GdkWindow.

ibus-1.4.99.20120428-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

On GNOME 3.6 integreated the input source, the behavior has been back as it did previously, which is ideal. that would means it may gives different UX among desktops. so I'm wondering if we should keeps this UI yet.

(In reply to comment #16)
> On GNOME 3.6 integreated the input source, the behavior has been back as it
> did previously, which is ideal. that would means it may gives different UX
> among desktops. so I'm wondering if we should keeps this UI yet.

GNOME has the plan to implement the similar UI.

You mean upstream is about to follow up to make a regression?

(In reply to comment #18)
> You mean upstream is about to follow up to make a regression?

No, I mean the switcher UI only.
If GNOME will have the better event handling, probably I can compare the behavior.
But currently I have no way to get GDK windows with XI2.

No? in fact that UI eats the key events. it's a regression anyway.

OK, I thought we agreed it's no problem whether the key event cancel the switcher or it's sent to the client applications in our initial discussion.

(In reply to comment #0)
> As we talked on IRC, I don't mind whether keep the switcher window open or
> not. if it's easier to do it after closing, that's fine.

Probably I didn't get your request.
I will investigate the comment #56 in bug 756595 but I'm not sure if it can resolve your problem.

(In reply to comment #21)
> (In reply to comment #0)
> > As we talked on IRC, I don't mind whether keep the switcher window open or
> > not. if it's easier to do it after closing, that's fine.
> 
> Probably I didn't get your request.
> I will investigate the comment #56 in bug 756595 but I'm not sure if it can
> resolve your problem.

Please read the summary again... it's all of my compliant. the above quote was to mention about the status of the switcher window. if you want to keep it during holding the ctrl key, I don't mind as long as the non-handled key events in ibus it surely delivered to the application, if it's easier to do it rather than closing.

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #0)
> > > As we talked on IRC, I don't mind whether keep the switcher window open or
> > > not. if it's easier to do it after closing, that's fine.
> > 
> > Probably I didn't get your request.
> > I will investigate the comment #56 in bug 756595 but I'm not sure if it can
> > resolve your problem.
> 
> Please read the summary again... it's all of my compliant. the above quote

I know it but I meant the initial discussion before you filed this.

I'd ask if the delivering the key events is still needed.
Currently the trigger key is Super+space and I guess other keys likes Super+a is not so important.
Probably I think you could assign Ctrl+space as an engine shortcut key instead.
Also GNOME switcher also has the same behavior.

If the feature is no longer needed, I will delete the internal patch.
The current internal patch just cancels Super+space.