| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML> |
| <HEAD> |
| |
| <meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2005. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > |
| |
| <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> |
| <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> |
| |
| <LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css"> |
| <TITLE> |
| Workbench key bindings |
| </TITLE> |
| |
| <link rel="stylesheet" type="text/css" HREF="../book.css"> |
| </HEAD> |
| <BODY BGCOLOR="#ffffff"> |
| <h2>Workbench key bindings</h2> |
| <p>The workbench defines many keyboard accelerators for invoking common actions |
| with the keyboard. In early versions of the platform, plug-ins could |
| define the accelerator key to be used for their action when the action was |
| defined. However, this strategy can cause several problems:</p> |
| |
| |
| <ul> |
| <li>Different plug-ins may define the same accelerator key for actions that are |
| not related.</li> |
| <li>Plug-ins may define different accelerator keys for actions that are |
| semantically the same.</li> |
| <li>Plug-ins may define accelerator keys that later conflict with the workbench |
| (as the workbench is upgraded).</li> |
| </ul> |
| |
| |
| <p>In order to alleviate these problems, the platform defines a configurable key |
| binding strategy that is extendable by plug-ins. It solves the problems |
| listed above and introduces new capabilities:</p> |
| |
| |
| <ul> |
| <li>The user can control which key bindings should be used.</li> |
| <li>Plug-ins can define key bindings that emulate other tools that may be |
| familiar to users of the plug-in.</li> |
| <li>Plug-ins can define contexts for key bindings so that they are only active |
| in certain situations.</li> |
| </ul> |
| <p>The basic strategy is that plug-ins use <b>commands</b> to define |
| semantic actions. Commands are simply declarations of an action and its |
| associated category. These commands can then be associated with key |
| bindings, actions, and handlers. Commands do not define an implementation |
| for the action. When a |
| plug-in defines an action for an editor, action set, or view, the action can |
| specify that it is an implementation of one of these commands. |
| This allows semantically similar actions to be associated with the same command.</p> |
| <p>Once a command is defined, a <b>key binding</b> may be defined that |
| references the command. The key binding defines the key sequence that |
| should be used to invoke the command. A key binding may reference a |
| <b>scheme</b> which is used to group key bindings into different named |
| schemes that the user may activate via the |
| Preferences dialog.</p> |
| <p>This is all best understood by walking through the workbench and looking at |
| how commands and key bindings are declared. We'll look at all of this from |
| the point of view of defining key bindings for existing workbench actions. </p> |
| |
| <p> |
| See the <a href="workbench_cmd_bindings.htm" class="XRef">org.eclipse.ui.bindings</a> |
| section for simple binding scenarios and the |
| <a href="workbench_cmd.htm" class="XRef">Basic workbench extension points using commands</a> |
| section for using the new command framework. |
| </p> |
| |
| |
| |
| </BODY> |
| </HTML> |
