Community
Participate
Working Groups
On I20031211, Pascal is reporting that he cannot use the 'F6' keyboard accelerator. This is bound (by default) in the "Default" key configuration.
I can now use F6 again. It seems that the problem was coming from my existing workspace. When I started I20031211 on this existing workspace F6 was not working. I changed the key bindings and it was still problematic. Finally I reset them to "default", shutdown and started up again, and everything was fine.
This might be important: can you tell me what version of workspace you were using previously? Something like "I opened a workspace from I200312xx in I20031211".
I believe that my workspace was from I20031209
The workaround is to use the keys preference page to change your key configuration and then restart Eclipse. The problem occurs with old workspaces using both the default key configuration and the new 3.0 key configuration. (Perhaps related (perhaps not) is menu disablement problem. The entire source menu was sometimes disabled.)
I have just tested (on Windows XP), the following scenario: open Eclipse (key bindings don't work), immediately close Eclipse, open Eclipse again (key bindings do work). Changing the key configuration may be a red herring.
I haven't be able to figure out how to get the bug "back" once I've restarted Eclipse. It's making it hard to reproduce. Opening the workspace with an older version, exiting, and the opening with a newer version doesn't seem to do it....
I also seem to recall the main Workbench preference page not appearing. Could this be an activities related problem?
i loaded 0800 (i was using 1227 from yesterday) and i got the problem again. i close and restart fixed it. now i can't get it back either. weird. i'd like to think we have a self-correcting problem where persisting the workspace simply fixes the problem. ps. doug, these are your bugs until you can show that its a problem with the engine..
This bug exists on all platforms and operating systems. However, I cannot reproduce this problem. I have even tried hitting up other people for workspaces. It is not simply a matter of an old workspace; there is something more to it than that. Is it perhaps possible that only a workspace that has gone through a particular series of integration builds can see this corruption? I'm going to mark this bug as "WORKSFORME". I can't reproduce, and I can't figure out why this would occur. If anyone has more information, please re-open this bug.
this can be reproduced regularly. i can't guarantee you exact steps, but i've been stuck on this all day upon returning from running the runtime workbench. perhaps the fact that the runtime workbench shell closes? anything happening with Shells in the past few days? (I saw some stuff in WorkbenchKeyboard about Shell stuff?)
Closing the workspace fixes the problem -- unfortunately, forever. Once a workspace is closed normally I can't reproduce the problem. I've been without a workspace that is broken. If you have a broken workspace, please make it available on the network file shares.
this is not a problem of older workspaces. the proof is easy: i started with a clean workspace this morning with today's 0800 I-build. i have always been able to fix this problem by restarting. sometimes this problem recurs. i notice it has recurred shortly after closing a run or debug session.
*** Bug 48627 has been marked as a duplicate of this bug. ***
I can now reproduce this problem in a self-hosted workspace. STEPS TO REPRODUCE: 1.) Open a fresh workspace (self-hosted possible) 2.) Open the CVS perspective. 3.) Add a pserver connection to dev.eclipse.org and checkout some modules. 4.) Switch to the Java perspective as the checkout is occurring. 5.) Import binary projects to fill the gaps. 6.) Press "Ctrl+Shift+T". DESIRED RESULTS: The "Open Type" dialog should open. ACTUAL RESULTS: The dialog does not open. Debugging println statements in WorkbenchKeyboard indicate that no key down events are being received.
An update: Step #5 is not necessary. At Step #6, the cursor is not visible even though both the editor view and the window appear to have focus. Clicking within the editor causes the cursor to appear, and the key bindings start working.
Refinement: In a running workbench, switch to the CVS perspective and then switch back to the Java perspective. "Ctrl+Shift+T" does not work.
SWT: Can you comment on this bug? We have a key filter enabled on Display, and we are not receiving key events. To see the effect you can do the following (I20031211): 1.) Open Eclipse with a fresh workspace. 2.) Switch to the "CVS Repository Exploring" perspective. 3.) Switch back to the "Resource" perspective. 4.) Press "Ctrl+Shift+R". If done with a debugger, it can be shown that our key binding listener is not receiving any events (WorkbenchKeyboard.filterKeySequenceBindings). Other things to note: the key binding listener is removed and added back once during initial start-up, and is removed and added back twice when switching to the CVS perspective. This is to disable key bindings while performing a blocking operation.
Ooops. Missed one step: 1.5) Switch focus to the navigator view, and then back to the welcome editor.
Debugged this with Doug and determined that there were 2 problems, one his and one mine. The GTK problem was fixed in the latest accidently by Grant (when a control was hidden, GTK was assigning focus to nowhere). Moving back to UI.
The remaining bug I believe has to do with focus percolating through the workbench. We are now receiving events, and I'm beginning to debug this problem. This bug may be related to Bug 48644 -- where menu items are disabled.
At least part of the remaining problem is tied into the incorrect updating of handlers. I'm not sure why this is happening... open eclipse ----> open resource has a handler switch to cvs perspective ----> open resource does not have a handler switch back to resource perspective ----> open resource does *not* have a handler The "setActionsById" method is getting called however, just with a bad map....
This will likely not be fixed before the warm-up build on Monday morning. Many apologies.
Getting closer to understanding what's going on. It looks like the action set itself is being cleared somehow. When the resource perspective is initially opened, the action sets look like: actionSet[0] = "Help Search"@{ &Help... } actionSet[1] = "Resource Navigation"@{ &Resource..., Open Reso&urce... } actionSet[2] = "Editor Navigation"@{ Go to Last Edit Location } actionSet[3] = "Search"@{ &File..., Se&arch... } actionSet[4] = "Open External Files"@{ Open External File... } actionSet[5] = "Help"@{ &Help Contents } actionSet[6] = "Software Updates"@{ &Manage Configuration..., &Find and Install... } actionSet[7] = "ReadMe Actions"@{ &Open Readme Browser, &Open Readme Browser (Retarget), &Open Readme Browser (Retarget - Label Update) } actionSet[8] = "External Tools"@{ &External Tools, &External Tools } When opened the second time, the action sets look like the following. Notice that the "Resource Navigation" action set is now empty. Also a bit puzzling is that there is a null action set. actionSet[0] = "Help Search"@{ &Help... } actionSet[1] = "Resource Navigation"@{ } actionSet[2] = "Editor Navigation"@{ Go to Last Edit Location } actionSet[3] = "Search"@{ &File..., Se&arch... } actionSet[4] = "Open External Files"@{ Open External File... } actionSet[5] = null actionSet[6] = "Help"@{ &Help Contents } actionSet[7] = "Software Updates"@{ &Manage Configuration..., &Find and Install... } actionSet[8] = "ReadMe Actions"@{ &Open Readme Browser, &Open Readme Browser (Retarget), &Open Readme Browser (Retarget - Label Update) } actionSet[9] = "External Tools"@{ &External Tools, &External Tools }
I have traced the problems to a change made to ActionPresentation on December 9th (committed by Tod, but the change was to support Kosta's cool bar work). Reverting to revision 1.9 fixes the problem. In speaking with Kosta, it seems that he's tried to introduce a third state for action sets (and action bars?). Previously, they would either exist or be disposed. Now, they can exist, be deactivated or be disposed. Deactivation being a kind of "soft dispose". Unfortunately, the code that reactivates the action sets and action bars does not handle this new state properly. This results in action sets becoming trapped in a deactivated state. This bug may still be related to Bug 48644. I have yet to make a reproducible test case for that bug with which to test.
There may be more to it then just the ActionPresentation change. If what I describe is a wholly unrelated bug, please file it separately and assign it to me. STEPS TO REPRODUCE: 1.) Open a fresh workspace, create a java project (switch to java perspective). 2.) Create a new class. 3.) Switch to welcome editor. 4.) Switch to java file. 5.) Switch to resource perspective. 6.) Switch to welcome editor. 7.) Switch to java file. OBSERVED RESULTS: At steps #2 and #5, the source menu does not appear with key bindings and the missing key bindings do not work. At steps #4 and #7, the key bindings do appear. Basically, switching perspectives or opening an editor does not appear to update the key bindings, while switching editors does.
Created attachment 7168 [details] Apply patch to ActionPresentation.java This patch fixes key binding problems. Apply as described.
The patch fixes key binding issues. Apply the patch to ActionPresentation.java.
This patch has been applied to CVS, and should appear in I200312160010.
*** Bug 48614 has been marked as a duplicate of this bug. ***
Problem is still there in 20031216
also see bug 48832
I am still using an old workspace which was previously running on 20031211, where I had some key binding issues (different sessions had different problems). But this time around it feels like all key bindings are gone, and I do not get any different behavior from a session to the other.
What Philippe is seeing sounds more like the original problem reported here, not the problem with action set handlers. It's not working when first started up. He did not say he was switching perspectives. Philippe has posted his workspace to ott4f under /teams/Eclipse- Platform/anon/in/48486.
*** Bug 48832 has been marked as a duplicate of this bug. ***
This bug, as described, seems fixed. The problems described by Philippe don't seem to be a new bug.
Created attachment 7184 [details] Configuration info from my workspace
