[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ui-dev] RFC: Key Bindings Proposal (end date = Dec 14, 2001)
|
See SA>Comments below...
Simon :-)
Kai-Uwe_Maetzel@xxxxxxx
Sent by: To: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-admin@e cc:
clipse.org Subject: RE: [platform-ui-dev] RFC: Key Bindings
Proposal (end date = Dec 14, 2001)
12/11/2001 02:24 PM
Please respond to
platform-ui-dev
There are two scenarios for which it is unclear to me to which degree they
are covered by the proposal:
1) The workbench defines a framework for implementing custom text editors.
One of the key classes is AbstractTextEditor. AbstractTextEditor together
with the underlying StyledText widget defines a set of standard editor
actions such as for navigation. Presumably, the workbench will define a key
mapping set covering all of these standard actions. A custom editor
extending AbstractTextEditor might introduce new actions. Thus, an
additional key mapping set is defined covering the newly defined actions.
What happens if the two key mapping sets are not disjoint? Are those two
key mapping sets conceptually merged together or chained defining an
accelerator search path?
SA> The workbench will define a list of common action ids (such as the
standard actions for navigation). Each key binding set can then reference
these ids to assign accelerator keys. The editor will then be able to
"register" with the workbench to have its actions invoked when the
accelerator key is pressed. For example, workbench will define a common
action id "go to start of line". The active key binding (determined by the
user) assigns the Home key to "go to start of line". The editor, when
active, will "register" with the workbench. When the "go to start of line"
is invoked by the accelerator key, the editor's action is run. Now the
implementation details have not been fully worked out yet - the goal of the
proposal was to make sure we were on the right track to meet user needs.
SA> If the custom editor (extending AbstractTextEditor) adds new action, it
is responsible to map it to the list of common action ids provided by the
workbench. Now if there is no match, then the editor decides what the
accelerator key will be - just like it does now. For example, say the
custom editor is an HTML one and it has an action to insert code to some
Java Bean. Since the action is pretty specific to the type of editor, it
won't show up in the list of common action ids. Note if the accelerator key
for that action conflicts with what is in the active key binding set, the
key binding wins.
SA> To change the accelerator key for that action of the custom editor
(like insert code to some Java Bean example), it can be done by the user
thru some ui (that will be part of another proposal later on). Or, the
developer providing a key binding map may know of the custom editor action
id and include it in the key binding set he/she is creating. That would
override the accelerator key provided by the editor for the action.
2) Built on scenario 1, assuming there are two plug-ins both with custom
editors and additional key mapping sets. What happens if the two plug-ins
define an accelerator for the same action id and do not restrict the
accelerator's scope to a particular editor. Which accelerator is eventually
used in each of the custom editors? In addition, lets assume that both
plug-ins redefine the accelerator for the save action id. How does it
affect the default text editor? Which accelerator is used in the default
text editor?
SA> Editors do not define key mapping sets, they only define actions just
like they do now. The editor can specify that the action be registered to
run for one of the common action ids accelerator key.
SA> In the workbench, only one editor's actions are active at any one time
(not counting when a view is active). So if both editors each have an
action with the same accelerator key, only the action for the active editor
is run.
SA> Each editor can define an accelerator for the save action. But when the
editor becomes active, it will "register" this save action with the
workbench active key binding set, and therefore the accelerator define in
the key binding set for the common save action id will be applied.
SA> Now, it is possible an editor developer will choose not to register any
of its actions with the workbench key binding set when activated. The
developer will then have to deal with two problems: 1) the user will be
annoyed that the key binding set he/she choosed is not working in that
editor. 2) SWT* will be trapping the keys as defined in the key binding set
so some keys will not make it to the editor, therefore the editor will seem
broken to the user. (* I'm assuming here SWT will be doing this for us)
Kai
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
