-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Key bindings for custom commands get lost when Eclipse is restarted #5
Comments
Adding keybindings to custom commands is already possible, but broken (see below). Since custom commands are currently broken anyway (see #47) there is no point in working on this issue, unless #47 got fixed. The following bug description was written when custom commands still worked, so bear that in mind: The plug-in needs to be already activated to define the keyboard shortcut and also to use it. That is, right now, the user would need to open the StartExplorer context menu and open the custom command section at least once to activate the plug-in, only then key bindings of custom commands could be used. Afterwards, the key bindings for all custom commands can be defined via the standard Eclipse mechanism (Preferences -> General -> Keys), the custom commands are available as "StartExplorer Custom Command 000", "StartExplorer Custom Command 001", ... The bindings are also saved in preferences. Only, on next startup they are not usable as long as the plug-in has not been activated (see above). To support this better, three things should be changed:
|
I think key binding gets lost when Eclipse is restarted. The commands are named: StartExplorer Custom Command 000 I mapped a key combination and verified that it worked. But it would not work when I restart Eclipse. It looks like the names are changed after the plugin is "activated" because the command would looks like this now: StartExplorer Custom Command 003 |
+1 |
http://www.eclipse.org/forums/index.php/m/290410/
http://dev.eclipse.org/viewcvs/viewvc.cgi/platform-ui-home/R3_1/contributions-proposal/requestForComments.html?view=co
The text was updated successfully, but these errors were encountered: