[
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 my SA> Comments below...
Simon :-)
Claude_Knaus@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/12/2001 12:16 PM
Please respond to
platform-ui-dev
My comments to the key binding proposal...
EMACS
I'd like to add that Emacs supports accelerators of infinite
depth, not just two levels. That said, I couldn't
find any key accelerator requiring more than three key strokes.
The manual says that accelerators with more than 4 keys are very rare.
Note that every key has it's own key modifier mask.
SA> This will be implementation details... from a usuability point of view,
a couple of level of keys each with its own modifiers it complicated enough
for a user to learn and memorize.
Some IDEs support accelerators with only two key strokes, some
don't even support a modifier on the second key stroke.
If we were to implement something like multi-level accelerators,
there's also the issue of display of these accelerators in the
menus. In Windows, the accelerators are typically left-aligned,
which might look very ugly depending on the maximum accelerator
level-depth. In Emacs, the acelerators are aligned to the right.
KEY BINDING SET
Reading the proposals and comments, I came to the following
conclusions.
I think there should be the concept of scope and key binding set.
Also we need two kinds of bindings, key bindings and action bindings.
Key
A sequence of keys, each with a modifier mask (Emacs support).
Synonymous to accelerator.
Action ID
A name identifying a 'common' action.
Example "Copy", "Paste", ...)
SA> What do you call the id of an action that is not "common" (see below)
Action
A concrete action.
Example: Any instance of a jface action.
Key Binding
An *-1 association of a key with an action id.
Any number of keys can map to an action id.
An action id does not need to be associated with a key.
User configurable.
Action Binding
A 1-1 association of an action with an action id.
SA> Actions already have an ID. They need one to be identified. In the
proposal, the suggestion is to include another attribute to the action to
link it with a common action id. Read the proposal again for more info.
Key Binding Set
Key binding sets build a tree hierarchy similar to class
hierarchies.
A key binding set declares new actions, which are associated
either with inherited action ids (overriding) or new action ids
(action binding).
New action ids may have default key bindings. In general
Newly added default key bindings should not
be conflicting (by convention) with the key bindings
associated with purely inherited action ids. Also, they
must be unique among themselves. These requirements should
be easy to satisfy, since everything is known at development
time.
SA> You lost me here. Probably because Key Binding Set is defined
differently in the proposal. Who is providing this Key Binding Set? Why are
there new actions in them? To what editor/view to these new actions belong
to?
Scope
Each scope has an associtated spatial object (widget,
ViewPart/EditorPart, global, ...) based on the focus.
Scopes are hierarchical trees as well, but have nothing to
do with the hierarchy of the key binding sets.
In Eclipse, three levels (widget, ViewPart/EditorPart, global)
of hierarchy should be sufficient. For example a text widget
overrides CTRL-C for all 'surrounding' scopes.
SA> I'm not convinced about this Scope part. How does the user specify the
key binding set to use for each Scope? If as a user I want to use emacs
style accelerator keys, should it not be so in all editors, widget, global
actions?
Algorithm
When a key is hit, the closest enclosing scope with respect to
the focus is found. For this scope the associated key binding
set is asked for an action. If an action is returned, we're done.
If no action is returned, the key binding set forwards the request
to its parent aso. If no action was found for this scope, the
parent scope is asked for the associated key binding set, of
which an action is requested, aso.
Menu Items
To consistently reflect the 'active' and 'inactive' (overridden)
actions, the menu items have to be grayed out accordingly.
-> Every focus change implies an update of the menus.
SA> Are you suggesting all possible actions be placed in the menu all the
time? Currently, only the active editor's actions are shown in the menu.
Maybe I'm not understanding your suggestion here...
What I mean by consistency: If there are several menu items
sharing the same accelerator, at most one menu item of them will be
not grayed out due to the overriding rules.
SA> Would it not look really weird to see 4 actions in a menu all with the
same accelerator key? I've never seem that before in an application.
Implementation Details/Issues:
* Since in SWT, the label (incl. accelerator) and the actually
active accelerators are independent, it should be possible
to ignore SWT's accelerators and handle accelerators by one
single mechanism.
* Updating menus on focus change might be costly, but
could be done also lazily on menu selection (does
SWT allow that?)
Independent Contribution
It should be possible to contribute key binding sets to a scope.
This is required for plugins which want to contribute an
action to a particular editor/viewer or to the workbench.
The problem is that default key bindings of such contributions
may conflict with other contributions which don't know
anything of each other. A solution would be to ignore the
any conflicting default key bindings in contributed key binding
sets or define some precedence order among the contributors.
SA> See the proposal to understand how we will handle collision of
accelerator keys.
