Community
Participate
Working Groups
20030206 gtk build. On Suse 8.1 pressing Ctrl-F1 flashes the view in focus, but does not open help info pop. It works fine on RedHat.
The view flashes so Workbench must be receiving the event, but IHelp.displayContext is not being called.
It doesn't open on RH8.0, KDE either. No flash in this scenario. If I run motif on RH8.0 and KDE F1 help does work.
As per comment #2 I put a break point in TaskList#CreatePartControl, at the call to WorkbenchHelp.displayHeop(contextId). Running on the same linux machine, at the same time I ran both motif and gtk. On motif the breakpoint is hit, on gtk it is not. It appears the help event is not being passed. I am of course assuming the help key (F1) is the same on both gtk and motif.
The help key for GTK build is Ctrl-F1 (F1 is on motif builds). I tried Ctrl-F1 on RedHat8.0 with KDE desktop, and it behaves same as on Suse8.1. The view flashes, no infopop. When I originaly wrote it works with RedHat, I was using GNOME.
I have four virtual desktops with my kde. ctrl-f1 thru ctrl-f4 switch desktops. These keys are intercepted by the OS, so eclipse never sees them, thus I don't see the flash you are talking about. I just switched to only one desktop, so ctrl-f1 still does not work, nor does ctrl-f4. Again I believe this is because the OS is intercepting these key strokes. Does Suse have virtual desktops which are accessible via ctrl-f1 thru ctrl-xx? Switched to gnome, ctrl-f1 help works. Now to find a Suse installation ...
Suse 8.1 by default logs on to KDE, that has 2 virtual destkops. Ctrl-F1, Ctrl- F2 switch between them.
Eclipse 20030211 RH8.0, GTK2.0.6 Ctrl-f1 appears to be help on GTK Ctrl-f1 is used by KDE to switch to the first virtual desktop. I have four virtual desktops, so ctrl-f1 through ctrl-f4 are hijacked by KDE and eclipse never sees them. On my session ctrl-f4 will not close an editor, but I can remap to ctrl-w and it closes (thus why I assume KDE has hijacked the key sequence). If I switch to gnome still running gtk ctrl-f1 does open help, and ctrl-f4 closes editors. I put a break point in Control#gtk_show_help. The break point is hit on gnome, but not KDE. From comment #6 I assume the same key hijacking is occurring on Suse. I believe the flash observed is actually the window manager switching to the first virtual desktop. The only flash I have observed on RH8.0 would suggest that. There was no help box openning flash, only a refresh of eclipse. Routing to SWT for further investigation and recommendations.
It seems that in KDE "F1" is the help key. I do not know why we have to use "Ctrl-F1" with GTK. I think it is perfectly fine if it can be made that F1 key opens help when Eclipse GTK is run on KDE destkop (or any desktop for that matter). I tried adding key listener to the widget, and receive events for F1 being pressed. If this is incorporated into SWT, it would solve the problem I think. I have also noticed that on Suse "Shift-F1" opens help pop-up. But the behavior is wrong. Multiple pop-ups flash and dissapear, and the last one that stays shows the context help for the workbench, not the widget in focus. It loooks to me like pressing Shift-F1 delivers not just to one event, but also to all the parent widgets and therefore the behavior described.
RH8.0, GTK2.0.6 Today while looking around the Control Centre for KDE I came across shortcuts uner Look&Feel. Under the shortcut Schemes Tab, then the Global Shortcuts tab System->Desktop Switching (are we there yet?) I removed the Switch to Desktop 1 shortcut (ctrl-f1). Help now works on GTK. Is there similar stuff on Suse? I turned off ctrl-f1 thru ctrl-f4 so I can even close editors now!
Same thing is on Suse( but need to choose "Shortcut Sequences" tab instead of "Global Shortcuts" tab). Disabling the "Ctrl-F1" shortcut there allows this combination to bring help infopop in Eclipse. Now, if you go the last tab - "Application Shortcuts", the value of the "Help" / "Help" shortcut is "F1". Eclipse does not honor this.
Sorry, meant Shortcut Sequences in comment #9 for KDE as well. You are correct F1 is not honoured. Now to update my look&feel so I can tell which tab is selected ...
*** Bug 33096 has been marked as a duplicate of this bug. ***
We know that: Crtl-F1 to Ctrl-F4 are used by KDE. Ctrl-F1 is the help key for Gtk. As far as I understand you are running GTK on KDE, therefore you are not able to have the help event. Then, you change your KDE options to let the Ctrl-F1 to go to the applications. What causes the help event to happen in Eclipse. Then, you change your KDE options again to set F1 as the help key, but you still have Ctrl+F1 as the Help key on Eclipse-GTK. Is that all right ? If yes, I can see any problem in this scenario. I think changing a KDE option would change the behavior of a GTK app, KDE is qt related not GTK. Please, try to verify this behavior running other GTK/Qt apps. Let me know what happens.
I am not setting F1 as the help key. What I ment in comment 10 is that the third tab of Look and Feel -> Shortcuts, named "Application Shortcuts", by default has already a mapping of F1 shortuct to Help action. I was not changing it. Some application react and display help after pressing F1. The problem in this bug was no way to get context sensitive help when running Eclipse GTK on Suse 8.1 (KDE by default). Andrew found out that removing Crtl-F1 mapping in KDE, works around the problem. The remaining issue is that context sensitive help does not work by default, but requires changes to desktop configuration. As a user, I do not know all relationship between KDE, qt, and GTK, but looking at KDE Shortcuts window, I see F1 mapped to help action, and Ctrl-F1 mapped to "Switch to desktop 1". I do not think many users will figure out that removing Ctrl-F1 KDE shortcut is required to make context sensitive help work. I have not been able to figure it out myself. I think this should be fixed that either Ctrl-F1 or F1 works by default. Suse 8.1 is a primary supported platform. If that is not possible, may be some other means of triggering context sensitive help can be implemented by SWT or UI (a special button on the application bar, entry in the context menu, I do not know), or in the worst case documented in the readme (it was not in 2.1).
What we have here is a conflict between GTK x KDE and there is nothing SWT can do. Is not a problem on Eclipse or SWT. You have your point and I do agree with you. But the help mechanism used by eclipse-gtk is complete provide by GTK. If you look at the code you will see that SWT just hooked gtk_show_help signal on GTK and send a SWT.Help event. SWT has to honor platform behavior, if GTK apps uses Ctrl+F1 to help that's what eclipse GTK will use. SWT can't choose a key out of blue to use as an alternative help key. It won't work. Imagine if GTK changes the default help key in the future, how messy it would be for eclipse users. Enter a bug against GTK or KDE, I would like to know what they have to say about this. I will add an new entry to SWT FAQ about this anyway.
I've entered a problem report against GTK about this: http://bugzilla.gnome.org/show_bug.cgi?id=110220
Sorry, the problem IS documented in the 2.1 readme - for all Ctrl+Fn keys (bug 26361).
*** Bug 58605 has been marked as a duplicate of this bug. ***
