Community
Participate
Working Groups
Reporter:Louis Cai OS: RHEL WS 3.0 -GTK Language: CHS Build level: M8-200404329 JDK Version: IBM JDK 1.4.2 Beta Test case #: Summary: DBCS: After pressing "Tab", anything can not be inputed. Description: Steps to recreate problem: 1- New a Plug-in Project, input DBCS in the Project name field, then click Next. 2- Place cursor in the field of "Runtime library", press "Tab" key, then try inputing SBCS or DBCS data in the "Source Folder Name"field. <<Error>> After pressing "Tab", anything can not be inputed. <note> After pressing "Tab" key, in other panel, we also can not input any character. </note> <<Expected Result>> After pressing "Tab", whether DBCS or SBCS can be input in the field.
Created attachment 9199 [details] picture for step 2
Our build level is wswb-30M8-200403291703, sorry for the mistake.
So you are using a wswb product? If so then this is probably built on top of eclipse 2.1.3. FH if you cannot reproduce this then it may be fixed.
Yes, we are using a wswb product, and the build level is wswb-30M8- 200403291703.This problem only ocurrs on the CHS language of RHEL WS 3.0 -GTK platform.
I think this bug is not SWT, please see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106807 http://bugzilla.gnome.org/show_bug.cgi?id=123580
We found we can press "Tab" on the linux system(RHEL WS 3.0 -GTK), and it can work well, also we can input character.
The problem is not in SWT. Download and compile that C code in Gnome bug (http://bugzilla.gnome.org/show_bug.cgi?id=123580): Bug 123580: Possible bug in GTK and miniChinput integration The link for the C code is: http://bugzilla.gnome.org/attachment.cgi?id=20388&action=view You can compile using the command line: gcc -o pr57408 pr57408.c `pkg-config --cflags --libs gtk+-2.0` Run it: ./pr57408 Steps: 1) Focus the first entry, open the input method 2) Press "Tab", the focus moves to second entry 3) Try to enter Chinese - BUG! The input method doesn't respond any more.
If you run eclipse on RHEL WS 3.0 -GTK(CHS), always the input method will don't work, and user can not input any SBCS or DBCS, user have to restart eclipse. It maybe very instability for user. Can any appropriate suggestion or solution for it?
Hi, Felipe 1.We have installed miniChinput-0.0.3-52.i386.rpm, but it seems not work, for the input method will not work occasionally; also we test it on eclipse of RHEL WS 3.0 -GTK, and the input method will not work occasionally. 2.We have download the C code and use the command "gcc -o pr57408 pr57408.c `pkg-config --cflags --libs gtk+-2.0`" on RHEL WS 3.0 -GTK, there will be some errors(See the attached file). Wait for your suggest. Thanks
Created attachment 9889 [details] Screen shot
You have to install the devel packages (for RH9.0 the packages names are:) gtk2-devel-2.2.1-4.i386.rpm glib2-devel-2.2.1-1.i386.rpm pango-devel-1.2.1-3.i386.rpm atk-devel-1.2.0-2.i386.rpm
We write a java code use javax.swing on RHEL WS 3.0 -GTK platform, after pressing "Tab", anything can be inputed eithor DBCS or SBCS. Is this a difference between SWT and Swing?
I don't how Swing implements the input method. SWT fails because GTK fails.
Hi Felipe, on our platform we have installed these rpms, the list as below is our rpm version. gtk2-devel-2.2.4.4.0 glib2-devel-2.2.3-2.0 pango-devel-1.2.5-2.0 atk-devel-1.2.4-3.0 We compile the C code you provided, and run it with "Tab", it can input chinese successfully. So we think we should reopen it. Thanks
Okay, what input method are you guys using ? Here, for Simplified Chinese, I use miniChinput-0.0.3. This is default input method for RedHat 9 (in North America at least).
We use the default IM of RHEL 3.0 WS. You can see the attached picture.
Created attachment 10037 [details] IM
our platform's version is miniChinput-0.0.3-51.0.
Please, test miniChinput version 0.0.3-56 available at: http://people.redhat.com/yshao/miniChinput/ The scenario described at comment#1 works as expected. For more information see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106807
Upgrading to miniChinput version 0.0.3-56 did not solve the problem for me. I'm using stock RHEL 3.0 WS.
Jonathan, could you please verify your miniChinput level and retry this. Make sure to retry the original scenario. If there are other scenarios that fail. Lets get them documented.
I can reproduce this on RHEL 3.0 with miniChinput 0.0.3-56. The basic problem is that once the tab key is hit, you can no longer enter input through the IME. Regular enlgish input still works fine. You can create this in any window where there are different fields to tab between.
Looks like this is still a serious problem and needs attention in 3.0.
Okay, I got a testcase that shows the problem, in RHEL 3.0 and in my machine (RH 9.0) as well. Steve: comment#22 is a good description of the problem, I believe this is caused by all that code we put in to implement filter keydown on a native text widget: The problem happens tabbing between two Text. The problem doesn't happen tabbing between two StyledText. The problem doesn't happen tabbing between two native GtkEntry (c code). The problem doesn't happen when I remove the filter key code from Text. The workaround right now is to close the input method before tabbing to other widget. I don't have a fix for the problem, given that code involved is very complicated it is not likely the fix will be safe for 3.0. Maybe, we could disable keyfilter for GB18030, but that would break the keybinding story.
Looks like a serious problem that needs fixed but it also sounds like the fix would be risky for this late in the 3.0 cycle. Could we get a call on this one for 3.0 (set Target Milestone to appropriate RC) or 3.0.1 (via a comment would be fine). If we do defer to 3.0.1, a workaround for the meantime would be good (hopefully better than closing the IME before tabbing, but if that is the best we can do...).
Created attachment 11615 [details] C example The bug is caused by a combinations of our key_down filter code and our own translateTraverse implementation. Here is a C example that recreates the problem.
I don't know how SWT tab (traverse) implementation is different from GTK's. Thus, don't know why the bug happens with one but not with other. Anyhow, there is two fixes that I tried (they both work): 1) Let our call to gtk_im_context_filter_keypress run for both Tabs keydown (we have a "gdkEvent.time != lastEventTime", that stops the second from running) 2) Don't call gtk_im_context_filter_key for Tab key at all. Note: a. when the IM is open is normal to receive two keydown events for every key stroke on a control key. b. "gdkEvent.time != lastEventTime" is a fix for some bug (infine loop when Return key is press)
Fixed in HEAD > 20040607 Please, download tomorrows afternoon integration build the verify the fix. Fix approved and verified by SN.
I've backported this to 3.0.1 a while ago just forgot to change the target milestone.
