Community
Participate
Working Groups
Reporter: Amanda Lee Language: Korean /Simplfied Chinese /Traditional Chinese Build driver: M4_Linux_GTK Severity: OS: RedHat8 JDK Ver.: IBM JDK1.3.1 + SR3 Test case #: 11.1 Summary: DBCS: "F1" funtion key does NOT work on Linux_GTK. Description: Steps to recreate problem: 1-Open a eclipse. 2-Press "F1" function key. ==> [Error] Nothing responded to. 3-Press "SHIFT+F1". ==> [Error] The pop-up resources tab and eclipse session are blinking, then no 'help' displayed. <<Expected Result>> The key bindings works correctly.
Moving this to the UI component, as this is a key binding issue.
F1 and Shift+F1 work on Motif with M5 build but still don't work on GTK with M5 build.
See bug 31329 for more information about f1/ctrl-f1 help and GTK.
Ctrl+F1 works on RedHat8.0 GTK2.0.6 (and also GTK+2.2) GNOME platforms.
I've reviewed this. We must use Ctrl+F1 on GTK to avoid confliction. This should be documented.
I can't reproduce this problem on Eclipse-GTK I20030910 using Simplified Chinese. 'F1' and 'Ctrl+F1' open the infopop help. 'Shift+F1' shouldn't display help. Running an application like GEdit, for example, only displays help on 'F1' and 'Ctrl+F1'. However, Eclipse does display help, after a very weird flicker (you have to see it to believe it). This is arguably a bug with SWT. I'm moving this to SWT for comment.
FH knows the complete story behind F1 and Ctrl+F1. Perhaps this is a dup and the explanation is alreay in another PR? FH to resolve this.
In GTK: Ctrl+F1 is the GTK_WIDGET_HELP_TOOLTIP help. Shift+F1 is the GTK_WIDGET_HELP_WHATS_THIS help. F1 is usually used as MenuItem accelerator, it brings up the Application Help. Due a bug in GTK (http://bugzilla.gnome.org/show_bug.cgi?id=100439) pressing F1 is the same as pressing Ctrl+F1. My options here are: 1) Don't do anything, I've verified that new version of GTK (2.2.4) which contaim the fix for GTK bug100439 does not have the problem. 2) Only issue SWT.HELP when the help type in show_help signal is equals to GTK_WIDGET_HELP_TOOLTIP, currently SWT fires SWT.HELP for each gtk show_help signal. 3) Stop using the show_help signal and start locking for Ctrl+F1 (or any key we want, like F1) to issue the SWT Help events. Try to fix bug 20841 with this as well.
Note there have been requests to make the help key remappable, both in Bug 20841 and Bug 26772. Note also that, if the help event could be triggered by the new platform-ui key binding architecture, we would avoid possible duplicate bindings (binding help and something else to the same key). This would also provide context-awareness -- perhaps providing an easy solution to Bug 26772. However, from the perspective of SWT as a standalone graphics library, it would probably be best to have some default behaviour. Perhaps providing global key filters before help processing? Is that even possible? Also, one of the key points I wanted investigated is the flicker effect when pressing "Shift+F1". Stop by my desk if you want to see a demonstation.
Fixed HEAD > 20030909 Crazy thing when Shift+F1 is fixed by SWT code. Ctrl+F1 / F1 problem was used by GTK code.
