Active input method prevents capturing a key on uim-pref since the input method steals user input. To avoid this, uim-pref should disable any input methods in toolkit layer. Disabling all uim input methods is insufficient because other input methods such as XIM also steals user inputs.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.