Community
Participate
Working Groups
I200408241200, GTK+ 2.4.4, KDE 3.2.3, Linux 2.6.7 I tried binding "Open editor drop-down" to "Ctrl+X B". If you then press, "Ctrl+X" and wait, a key assist dialog opens. This dialog is an override redirect window. Now, if you press "B", it will close the key assist dialog and open the editor drop-down. The editor drop-down is also an override redirect shell. Focus disappears. The second override direct shell never closes. You can click around, but I haven't managed to find a way to motivate keyboard focus to come back again.
I've to troble to bind "Open editor drop-down" to "Ctrl+X B". The key assist dialog never opened, is it a new feature only available in newer eclipse ?
On old versions, go to the advanced tab of the keys preference page, and ask to be helped. In newer versions, this is the default setting.
Works on my machine. Interesting how you system has all kinds of bug and my works fine :-(
This works the same on both our machines. The workbench window remains the active shell and focus remains in the workbench window. The editor drop-down can be dismissed by clicking on one of its entries. However, in more recent builds, focus does disappear forever. I'm running with I200409070800 now, and focus disappears.
Doug, I just update to build I200409070800 and now I can reproduce the 'keyboard stop working' part of the problem. I can move the caret around javaeditor but I can't type. To "motivate keyboard focus to come back again" I just need to open a dialog (like help->about).
Start with no editors open. Now, open the editor drop-down with the steps given in the description. There is no way to close the override redirect shell -- not even opening a dialog or clicking within the override redirect shell. This requires restarting Eclipse.
The key assist dialog is not ON_TOP, it is just NO_TRIM. This means it is managed by the window manager. Activating a key binding while the window is open triggers two competing focus operations: 1. The window manager is managing the NO_TRIM window, and tries to give focus back to Eclipse when the dialog closes. 2. The key binding triggers the ON_TOP window to appear, and SWT tries to give it focus. In this case, the window manager succeeds and SWT fails. Focus never gets to the ON_TOP window. However, Shell#bringToTop() does not consider this case, and aggressively marks the ON_TOP window as being active, which blocks key events to the main Eclipse shell. While I think that it is wrong to mark a Shell as active before actually getting a corresponding focus event, fixing that won't help this problem: the open editor dialog would appear, but not have focus (keys would work in Eclipse though). The fix for this bug is to call XSetInputFocus with a timestamp of 0, rather than the last event time. This is a violation of the ICCCM, but I think it is reasonable given that the Shell is an override_redirect window. This change should also avoid competing with the window manager.
Created attachment 20806 [details] Proposed patch
Fixed > 20050509, patch reviewed by SSQ
