Bug 2409

Please aware of the bug and assign to appropriate person by yourself.

"Component" has been changed.

I tested, but couldn't reproduced the situation that active input context 
steals user's key input. I want to know how to reproduce.

I tested with: uim-pref-gtk, revision 448.

Try follwing steps.

1. Configure skk as default IM
2. Open arbitrary key editing window by clicking arbitrary "Choose..." button
3. Click the textbox of the window to capture a key
4. Press "<Control>j". But it is stealed by skk. The textbox cannot capture it
5. Press "a" subsequently. It is also stealed by skk, and produces "a" as
hiragana The textbox cannot capture the "a" key, and polluted by IM commit

Although using dedicated capture window does not have the problem, it has
another problem.

1. Open the capture window by clicking "..."
2. Press "space", "return" or "<Alt>c"
3. It is stealed as accelerator of "_Close". User input cannot be captured

I think that we should disable the accelerator of this window.

Both capturing problems should be resolved.

I tested Yamaken's procedure with revision 514, but couldn't reproduced... 
Someone already fixed the problem?

Fixing of dedicated capture window seems difficult for me. Maybe we should
remove 'Cancel' button at 0.4.6 release.

Created attachment 1831 [details]
The textbox shows the problem with uim r514.

My environment is still having the problem with r514... See attached screenshot.

$ uname -sr
FreeBSD 5.3-RELEASE
$ pkg-config --modversion gtk+-2.0
2.4.14

Removing the cancel button from the dedicated capturing window as you said is
reasonable solution for 0.4.6, I think.

The textbox problem can be defferred to 0.6.0.

> The textbox problem can be defferred to 0.6.0.

How about this?  This is a hack to replace key capture's 
im_context in gtk_entry with gtk_im_context_simple.
It only affects key capture entries, so we can use Japanese
input method in other entries of uim-pref-gtk.

This may be very hackish, but works for me.  If it is acceptable,
I'll use this code and remove toggle button of shift, control, alt
in key capture window and use uim's notation of key combination.


--- pref-gtk.c.orig     Fri Feb  4 18:56:07 2005
+++ pref-gtk.c  Fri Feb  4 18:57:16 2005
@@ -532,6 +532,7 @@
   GtkWidget *hbox;
   GtkWidget *label;
   GtkWidget *entry;
+  GtkIMContext *im_context;

   hbox = gtk_hbox_new(FALSE, 8);

@@ -539,6 +540,12 @@
   gtk_box_pack_start (GTK_BOX (hbox), label, FALSE, TRUE, 0);

   entry = gtk_entry_new();
+
+  /* hack alert! */
+  im_context = gtk_im_context_simple_new();
+  g_object_unref(GTK_ENTRY(entry)->im_context);
+  GTK_ENTRY(entry)->im_context = im_context;
+
   gtk_box_pack_start (GTK_BOX (hbox), entry, TRUE, TRUE, 0);
   gtk_box_pack_start (GTK_BOX (vbox), hbox, FALSE, TRUE, 0); 

That would be great enough for 0.4.6. Please go ahead.

I think there is still one problem of key capturing.

Is there any way to avoid window manager's (or GNOME's) key shortcut?
If it is impossible, I can't remove toggle buttons of modifier keys
in uim-pref since it prevents setting key combinations which window
manager uses.

Do you have any idea of disabling window manager's key combination
temporarily?

> Do you have any idea of disabling window manager's key combination
> temporarily?

Arrg, I was too stupid about this.  If the key combination is used for window
manager, it is no need to capture this by uim-pref since it will
never used for text input...

I'll commit the change I mentioned in comment #9 soon.

Sorry for bother you.

r516 and r519 in new repository should fix the problem.