Community
Participate
Working Groups
Build 20020813 For some reasons F3 and F4 stopped working in several views. Also, [Delete] key doesn't work anymore in Search view without having changed anything there. I heard about an SWT change in that area? Since we are in non-breaking API mode for 2.1 I guess this changes needs to reverted.
Is this still a problem with the latest 2.1 build? Have you talked to SWT about this (i.e. any of their changes caused this problem). I'm not aware of any changes in this are at the workbench level that would cause this problem.
It's still a problem in I20020820. Also Ctrl+B does not work in the editor. I did not talk to SWT but Kai mentioned some SWT changes.
*** Bug 22697 has been marked as a duplicate of this bug. ***
Increased priority since this bug prevents us from using the latest integration builds for development.
The delete key doesn't work in any of the debug views either. I've noticed that if I create a key listener in a view, I only get keyReleased notifications for DEL, not keyPressed.
*** Bug 22904 has been marked as a duplicate of this bug. ***
We have 3 different problem caused by the same changes. 1) Ctrl + B 2) Del 3) F3 and F4 I have a fix for 1 and 2 which I am going to release in the head stream. The keybindind implementation and API used to work only for editors. So if you change the binding to "emacs" you would still get the default binding when a view was active. Once we got an answer from SWT on how to implement keybinding without having to have a key listener in the widget I moved the API and implementation to support views and editors. That caused the 3 side effects described above. PS. These changes will have to happen if we decide to implement a UI to configure keybingind. We have a couple of options here: a) revert the code b) fix the F3 and F4 problems. ** b) is a lot simpler then a). We just have to change the plugin .xml to point the actions from the action set to its definition ids. (definitionId="xxxx") ** if we decide for a) because we must not break anything then we are deciding that we will not have UI for keybing in 2.1 (that was not decided anyway and it involves a lot more then this changes) ** the only one using keybindings extension points in the platform is jdt ui. I.E it is the only one that was broken. I would vote for b) if KH and JDT UI team agrees with it.
I vote for b.) if this is what we have to do: for the two action below we add an additional attribute definitionId="xxx". <action id="org.eclipse.jdt.ui.actions.OpenTypeHierarchy" menubarPath="navigate/open.ext" label="%OpenTypeHierarchyAction.label" accelerator="F4" retarget="true" /> <action id="org.eclipse.jdt.ui.actions.Open" menubarPath="navigate/open.ext" label="%OpenAction.label" tooltip="%OpenAction.tooltip" description="%OpenAction.description" accelerator="F3" retarget="true" allowLabelUpdate="true"/> One more comment: we currently define an accelerator at three different place: - the label (@F3) - the action's accelerator attribute - inside an accelerator set Will this become a little easier in the future ?
In the future the first two ways to set the accelerator should be depracated and the last one (accelerator set extension point) should be enough. We should spend 5 extra minutes and check the other jdt actions defined in action sets. All actions that have an accelerators and a definition id should have the definitionId tag defined in the action set.
*** Bug 23238 has been marked as a duplicate of this bug. ***
Added definitionIds to actions in JDT/UI land.
ctrl-\ is also broken
Relased fix for Del and Ctrol+B. Will re-test next build before closing this.
Tested the fixes in the lastest integration build with the UI HEAD. Ctrl+B, F3 and F4 work. We still have a problem with "Ctrl+\" because it is defined in xml as "Ctrl+\\" but it should not have the double "\". Moving to JDT to fix "Ctrl+\".
I assume we had to escape the '\' to work in previous releases (i.e. 1.0 and/or 2.0). Not 100% sure what's the exact XML definition for "\\" values. It has been like this in 2.0 and worked fine. I assume something changed in platform-UI land regarding the parsing of accelerator keys. I changed it now to be "\". However, since the JDT 2.0 (or 2.0.1) plug-in no longer works on top of current platform-UI there must be a breaking change in platform-ui somewhere. Moving back for comment: - is using "\" the correct way? Why did we have to use '\\' in 2.0? - what about 2.0 plug-ins running on platform-ui?
*** Bug 22595 has been marked as a duplicate of this bug. ***
Yes, there was a breaking changing the plaform-ui but we can assume that we broke only JDT and we concluded that it would be better to fix the JDT plugin.xml. We all agree that there is too many ways to set an accelerator. The idea is to deprecate a bunch of them and use the only one (keybinging extension points). Since the new API could not be fully implemented in 2.0, we could not deprecate to old APIs. We want to deprecate it but we have to be backward compatible. In the case of Ctrol+\, it is set in many different ways. We used to pick the accelerator from the old APIs and now we are getting from the new one. I.E the line <accelerator key="Ctrl+\\" id="org.eclipse.jdt.ui.edit.text.java.uncomment" /> was never used in the default configuration and now it is.
>we can assume that we broke only JDT How can you assume this? Did I miss an e-mail on the mailing list where the developers have been asked? Since it is an API anybody might run into this.
The problem described in the bug report has being fixed. The keybinding design is being reviewed and this breaking change should be taken in consideration. I am not sure if we can implement keybinding custumization without this breaking change.
I am new to this PR. I understand that JDT has fixed its issues here. The new key binding engine is now in place (M2). Eduardo is correct that for this new key binding functionality to work, the breakage illustrated by this PR needs to be tolerated. Also, an email does need to be sent to the eclipse-dev mailing list regarding the new key bindings in general. I will be taking care of this myself shortly.
