After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702841 - GdkQuartz does not distinguish Eisu, Kana and Space keys on Japanese keyrboard
GdkQuartz does not distinguish Eisu, Kana and Space keys on Japanese keyrboard
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.24.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-06-22 00:51 UTC by Takuro Ashie
Modified: 2018-04-15 00:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A test program (1.26 KB, text/plain)
2013-06-22 00:51 UTC, Takuro Ashie
  Details
A patch to translate "Eisu" and "Kana" keys (2.05 KB, patch)
2013-06-22 01:32 UTC, Takuro Ashie
none Details | Review

Description Takuro Ashie 2013-06-22 00:51:54 UTC
Created attachment 247500 [details]
A test program

GdkQuatz translates Eisu & Kana keys on Japanese keyboard to
GDK_space although these keys should be translated to
GDK_KEY_Eisu_toggle & GDK_KEY_Hiragana.


Effects of this issue:

* Applications can't distinguish Eisu, Kana and Space keys.

* The "activated" signal of GtkEntry is unexpectedly emitted
  when you enable imquartz (bug694273) and press Eisu or Kana
  keys.
  I confirmed it on the compose window of "Sylpheed".

* On some third-party widgets, a space character is inserted
  unexpectedly when you enable imquartz (bug694273) and press
  "Eisu" or "Kana" key,
  I confirmed it on the source code editor of "Xamarin Studio".


Steps to reproduce:

1. If you don't have Japanese keyboard, install KeyRemap4MacBook
   to emulate Eisu & Kana keys by left & right Command keys.

  https://pqrs.org/macosx/keyremap4macbook/index.html.en

  After install it, enable following preferences:

  * "For Japanese" ->
    "Change Command_L Key" ->
    "Command_L to Command_L (+ When you type Command_L only, send EISU)"
  * "For Japanese" ->
    "Change Command_R Key" ->
    "Command_R to Command_R (+ When you type Command_R only, send KANA)"

2. Build attached test program (testbed.c) by following command:

  cc `pkg-config --libs --cflags gtk+-2.0` -o testbed testbed.c

3. Enable imquartz from the right click menu of GtkEntry

4. Press "Eisu" key.
   (Or left "Command" key if you use KeyRemap4MacBook.)

5. Press "Kana" key.
   (Or right "Command" key if you use KeyRemap4MacBook.)


Expected results:

* On pressing "Eisu" key, a following message is outputted:

  keyval: Eisu_toggle
  ("Meta_L" is also outputted if you use KeyRemap4MacBook)

  And a following message shoudn't be outputted:

  activated

* On pressing "Kana" key, a following message is outputted:

  keyval: Hiragana
  ("Meta_R" is also outputted if you use KeyRemap4MacBook)

  And a following message shoudn't be outputted:

  activated


Actual result:

On pressing "Eisu" or "Kana" key, following messages are outputted:

  activate
  keyval: space
Comment 1 Takuro Ashie 2013-06-22 00:54:28 UTC
gtk+-3.x has also same issue.
Comment 2 Takuro Ashie 2013-06-22 01:23:54 UTC
(In reply to comment #0)
> * The "activated" signal of GtkEntry is unexpectedly emitted
>   when you enable imquartz (bug694273) and press Eisu or Kana
>   keys.
>   I confirmed it on the compose window of "Sylpheed".

http://sylpheed.sraoss.jp/

Text entries on compose window of Sylpheed connect to ”activate"
signal to move focus automatically on pressing "Enter" key.

When you enable imquartz, this feature is misfired when you press
"Eisu" or "Kana" key. The mechanism of this issue is a little complex.

1. The key event is passed to GtkIMContextQuartz
2. GtkIMContextQuatz doesn't handle it
3. The key event is returned to the widget.
4. Subsequent behavior is different by implementations of widgets.
    When the widget doesn't handle the event, it is returned to 
    toplevel GtkWindow.
    (Some third party implementations may enter a space character at this step)
5. The window look up a key binding from GtkBindings.
6. I',m not sure but probably Space key is bound to "activate" so that
   "activate" signal is emitted.
Comment 3 Takuro Ashie 2013-06-22 01:32:10 UTC
Created attachment 247503 [details] [review]
A patch to translate "Eisu" and "Kana" keys

UCKeyTranslate() converts "Eisu" and "Kana" keys to "Space" key unexpectedly.
To avoid it,  this fix translates these keys by the same way for Function keys & KeyPad keys.
Comment 4 Matthias Clasen 2018-02-10 05:16:06 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 5 Matthias Clasen 2018-04-15 00:08:01 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new