Bug 810211 - The key events with ctrl key isn't delivered during the switcher window is open
The key events with ctrl key isn't delivered during the switcher window is open
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ibus (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: fujiwara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-05 07:06 EDT by Akira TAGOH
Modified: 2014-07-01 00:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-29 06:31:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch1 for upstream (859 bytes, patch)
2012-05-09 06:43 EDT, fujiwara
no flags Details | Diff
Patch2 for customizable Control+space (5.65 KB, patch)
2012-05-09 06:44 EDT, fujiwara
no flags Details | Diff

  None (edit)
Description Akira TAGOH 2012-04-05 07:06:19 EDT
Description of problem:
The switcher window is open when ctrl+space is pressed and keep it open until the ctrl key is released. this behavior is introduced since f17 though, the key combination with ctrl key could be sent to application without releasing the ctrl key in older releases. e.g. one may wants to move the cursor with ctrl+a and ctrl+e after turn off ibus. on f16 or older version, it could be done by the following sequences: ctrl+space (to turn off) -> ctrl+a (to move the cursor at the beginning of line) but on f17: ctrl+space -> release the ctrl key -> ctrl+a. need an extra step to accomplish it.  So that would be nice if we can keep the old behavior on f17 too.

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.

Version-Release number of selected component (if applicable):
ibus-1.4.99.20120317-2.fc17.x86_64
Comment 1 fujiwara 2012-04-24 06:09:44 EDT
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.
Comment 2 fujiwara 2012-05-09 06:43:26 EDT
Created attachment 583209 [details]
Patch1 for upstream
Comment 3 fujiwara 2012-05-09 06:44:20 EDT
Created attachment 583210 [details]
Patch2 for customizable Control+space
Comment 5 Peng Huang 2012-05-15 12:00:23 EDT
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.
Comment 6 Akira TAGOH 2012-05-15 22:08:07 EDT
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).
Comment 7 fujiwara 2012-05-15 22:59:38 EDT
(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.
Comment 8 Peng Huang 2012-05-16 10:11:49 EDT
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.
Comment 9 Akira TAGOH 2012-05-16 21:52:35 EDT
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.
Comment 10 fujiwara 2012-05-17 06:26:56 EDT
(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.
Comment 11 Fedora Update System 2012-05-18 06:53:17 EDT
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
Comment 12 Fedora Update System 2012-05-18 16:25:32 EDT
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).
Comment 13 Akira TAGOH 2012-05-20 23:42:43 EDT
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.
Comment 14 fujiwara 2012-05-21 03:23:34 EDT
(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.
Comment 15 Fedora Update System 2012-05-29 06:31:42 EDT
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.
Comment 16 Akira TAGOH 2012-08-06 05:32:23 EDT
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.
Comment 17 fujiwara 2012-08-08 22:01:28 EDT
(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.
Comment 18 Akira TAGOH 2012-08-08 23:18:15 EDT
You mean upstream is about to follow up to make a regression?
Comment 19 fujiwara 2012-08-09 00:26:32 EDT
(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.
Comment 20 Akira TAGOH 2012-08-09 01:39:54 EDT
No? in fact that UI eats the key events. it's a regression anyway.
Comment 21 fujiwara 2012-08-09 01:52:30 EDT
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.
Comment 22 Akira TAGOH 2012-08-09 01:58:35 EDT
(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.
Comment 23 fujiwara 2012-08-09 02:02:07 EDT
(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.
Comment 24 fujiwara 2014-02-13 02:52:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.