Re: [platform-ui-dev] RFC: Key Bindings Proposal (end date = Dec 14, 200

[Claude_Knaus@xxxxxxx]

see CK> for my comments

Claude :-)

Simon_Arsenault@xxxxxxx Sent by: platform-ui-dev-admin@xxxxxxxxxxx 12.12.2001 22:56 Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        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.

CK> I was just correcting the view that Emacs binding would
support only two levels of key strokes. Once limitations have
been set, it's hard to break them open again.
We should not assume what is hard for the user to do.
People are using emacs and the default configuration seem to support
very strange (for me hard to memorize as well) key combos. Yet, it seems that
for some people those key bindings make sense and are useable.
For example at home, I work with vi (not programming in Java obviously).
The vi commands are 'wired' in my fingers. If'm working with an another
editor which is supposed to act like vi, it would be intolerateable if a
particular key binding would be different and could not be changed
the way I'm used to. I believe this is what some people mean by 'the editor as
is is unusable to me'. Memorizing key bindings is not a matter
of mentally memorizing. It's like playing the piano or regular typing.
I don't remember under which finger which key sits. Yet,
I can do blindly whole sequences of key strokes w/o making mistakes.

  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)

CK> By inheriting a key binding set, you can share the 'common' id.
For example, you have a basic editor key binding set for text fields.
It would only support cut, copy, paste and undo. A text editor would then
extend the editor key binding set by a text editor key binding set by
adding action ids like "Go to line". The 'common' editor clipboard and
undo actions would be inherited. If the implementation allows it, even
the actions themselves are allowed to be the same (a copy action would
possibly copy text in a Java editor the same way as in a plain text editor).

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.

CK> I'm talking mostly about concepts, rather than implementation
here. I just wanted to start with defining the words, like
actions, action IDs, key binding, the way I understand them
to be able to refer to them later w/o misunderstanding.
Note that I meant 1-1 association within a key binding set here.
A key binding set extending another may override by associating
another action with the same action id. Globally, it's a 1..*-1
association. At most one action per action id would be executable,
depending on the scope.


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?


CK> The key binding sets would be provided by editors, viewer, text field
widgets, etc. They may inherit from existing key binding sets, or may
define new ones. A Java editor would add new actions with respect
to a plain text editor. The scope could be associated with the EditorPart.
A simple text field would just have a basic key binding set with editing
actions like copy, paste, undo, ... and its scope would be the widget.


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?

CK> That's a configuration issue. The user would be presented a
list of all available scopes. Each scope is associated with
a key binding set which the user can configure. The association
of a scope with a key binding set is done programatically and
would not be user configurable.
A Java editor would use a Java key binding set, whereas a C editor
would use a C key binding set, which may inherit from a common
editor key binding set.

SA> If as a user I want to use emacs
style accelerator keys, should it not be so in all editors, widget, global
actions?

CK> For most people the answer is very likely yes. That's something which
should be 'default' or easy to enable. Like some
IDE ship an Emacs configuration or support even an Emacs mode.
This might be enough for most people, but some want to fine tune it.
Or have exceptional behaviour for particular editors.
I see no reason to prevent a user from freely being able to configure
different editors, etc., but for the reason of implementation burden.
If Eclipse was not supposed to be a general application platform,
I would not have such strong feelings about this.

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...

CK> No. For instance, there are actions which are always there (Copy, Paste,
...). It may make sense to override these key-bindings in a particular
viewer or editor with other actions with completely different meaning.
Of course some of these viewer or editor specific actions modify the menus
dynamically and are not always present.

  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.

CK> Maybe because there hasn't been an 'application' like Eclipse before? :)
Actually I think I've seen it in Eclipse, but that was probably a bug :)

  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.

CK> I don't see the issue of action sets conflicting with other
action sets (what I call contributions) being addressed?

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev