Skip to main content

[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 :-)

                    Sent by:                       To:     platform-ui-dev@xxxxxxxxxxx                      
                    platform-ui-dev-admin@e        cc:                                                      
                               Subject:     Re: [platform-ui-dev] RFC: Key Bindings     
                                                   Proposal (end date = Dec 14, 2001)                       
                    12/12/2001 12:16 PM                                                                     
                    Please respond to                                                                       

My comments to the key binding proposal...


  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.


  Reading the proposals and comments, I came to the following
  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.


  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)


  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

  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

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


  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


  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.

Back to the top