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 me DB> Comments below ...


Sent by: platform-ui-dev-admin@xxxxxxxxxxx

12.12.2001 20:52
Please respond to platform-ui-dev

        To:        platform-ui-dev@xxxxxxxxxxx
        Subject:        Re: [platform-ui-dev] RFC: Key Bindings Proposal (end date = Dec 14, 2001)

See my SA> Comments below...

PS My comments will disagree with what your saying, but both your's and
Randy Hudson's point of view will be considered before the final decision
is made.

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 01:36 PM                                                                    
                   Please respond to                                                                      

I don't agree with the statement that the short cuts must be consistent
over all editors and that
users expect this behavior. Here are my reasons:

SA> I didn't say the user expects this behavior - rather we believe it
would be more consistent for the user.

- if we embed an editor using OLE the short cuts aren't consistent either.
For example if we load a Word document
 the short cuts will be different from the once defined for the rest of
the Eclipse editors.
- the same is true if we launch an editor as an external tool.

Since we can't be consistent in this cases we should not try to be smarter
in the others.

SA> We are aware of the problem with OLE editors and external editors. And
there is nothing we can do in these two cases. However, we can be
consistent for other Eclipse editors - which is where most users will spend
their time. There are other areas where the workbench tries to be
consistence across editors (for example menu contributions) but can't in
the case of OLE editor - that does not mean we give up for Eclipse editors.

DB> yes and no. What I was trying to say is that consistency is of course
something that is desirable, but we can't enforce it for the overall platform.
So I think user might be suprised that some editors follow that rule and others
don't. And for the user there might be no visual difference between an embedded
OLE component and a "native" eclipse editor. So how does he know that one is
a OLE editor with an inconsistent set of short cuts and the other a native one
with a consistent set of short cuts ?

IMO developers are used to different editors and their short cuts. So if I
edit an HTML file using a special HTML editor I know that
Ctrl+I is a short cut for Italic and if I edit a Java file using a special
text editor an know that Ctrl+I means indent. What I think is important
that short cuts stay the same when I use the same type of editor (text
editor A and text editor B). But if I use a special editor for special
editing (like a special HTML editor) I want special shortcuts for special
things. Otherwise I would use a normal text editor.

SA> Would you be proposing that the key binding set is tied to a specific
editor (or to many specific editors)? Something like, for my Java editor I
want the emac key binding, for my html editor I want the FrontPage key
binding, for the text editor I want the default key binding of Eclipse?

SA> What do you mean by "What I think is important that short cuts stay the
same when I use the same type of editor"? Could you give me an example?
What do you mean by a "special editor"? What makes it special? A valid use
case scenario would be helpful here to explain how you envision the user
working with these editors and accelerator keys.

DB> Yes, a concert example is always more helpful than some generic statements.
So here is what I expect from tools and their short cut consistency (the examples
are Windows specific. All this might be different under a different OS):

- if Eclipse provides editors for Java, C/C++, and other languages and all these
  editors have an action indent I would expect that this indent action has an
  consistent short cut lets say Ctrl+I. For me these editors all work on the same
  type of content: source files.
- if there is an editor to edit HTML files in a WYSIWYG way, than I would expect
  that Ctrl+I is bound to "Change font to Italic" than to indent, also I can
  indent text. For me a WYSIWYG HTML editor is more like Word so I expect to have
  the Word short cuts for this editor rather than the source editor short cuts.

So I would like to see different sets of short cuts for different kind of editors
(source editors versus WYSIWYG document editors (HTML, doc files, ..) versus
graphical editors versus ...).

  Sent by:                         To:        platform-ui-dev@xxxxxxxxxxx
  platform-ui-dev-admin@ec                                                                 cc:                                    
                                   Subject:        Re: [platform-ui-dev]  
                           RFC: Key Bindings Proposal (end date = Dec 14,
  12.12.2001 18:00         2001)                                          
  Please respond to                                                      

I understand your point of view.

In the proposal, I talk a little about this issue. We've decided to go the
route of Key Binding Set is king! That is, if Ctrl+I is assigned to the
common action id "Increase Indent", then that is what it will do in the
HTML editor (the set will provide another accelerator key for the common
action id "Italic").

Here is our reasoning. We believe applying the Key Binding Set all the time
will be more consistent to the user. It is a well documented fact that
users take time to learn accelerator keys and they get confused when it
changes between editors for the same type of action. Given the user in
Eclipse will be switching editors often, it would be a lot for the user to
note in which editor he is and ajust his/her thinking of what the
accelerator keys are now.  Maybe we are totally wrong here with this
assumption - that will be something that usuability tests will determine
(Julian, if you have any comments or data on this, please let us know so we
do not go down the wrong path).

As for your examples, if someone is using the "FrontPage" set, then most
likely the user is spending most of his/her time in the HTML editor. So
going to another editor is rare and therefore will probably be happy with
the global key binding idea.

If we allow editors to somehow override what the key set defines, then how
would this be shown to the user? Yes, actions that are in the menu could
have the accelerator text changed as the editor is activated but that is a
usuability no no as there is no feedback to the user unless he/she opens
the menu. There is also the problem of how much of the key binding set can
be overriden. Is that dependent on the "type" of key binding set (emac
users would probably not appreciate this...they want their emacs
accelerator keys all the time)

Simon :-)

                  "Randy Hudson"

                  <hudsonr@xxxxxxxxxx>           To:
                  Sent by:                       cc:

                  platform-ui-dev-admin@e        Subject:     Re:
[platform-ui-dev] RFC: Key Bindings
                             Proposal (end date = Dec
14, 2001)

                  12/12/2001 11:26 AM

                  Please respond to


After seeing your two examples of FrontPage and Interdev I realize that a
single set of key bindings for all editors isn't what the user wants.  For
source code, I want Ctrl+I to be Indent, but for HTML I want ctrl+I to be
Italics.  Making "Indent" for source editors use something other than
Ctrl+I because WYSIWYG editors use it for Italics would be a mistake.

I suppose WYSIWYG editors could still respect some of the key bindings that
are used in source editors, like "End of line", but it might ignore others,
like indent.  However, you have to define all key bindings or none.  If you
define just a subset, and the Editor has to supplement that subset, how
does it know to avoid conflicts?

Maybe there would be specific key-bindings for WYSIWYG source too, like
Enter maps to newline <BR>, while Shift+Enter maps to new paragraph <P>.


                  Sent by:                      To:

                  platform-ui-dev-admin@e       cc:

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

                  12/12/2001 10:01 AM

                  Please respond to


If I am correct, the goal of the key binding proposal is to remap the
accelerators for global actions + editor actions.  For instance, you may
apply Emacs keybindings to the environment.  Emacs is more than just Find,
Save As, etc.  It also involves go to end of line, indent, Capitalize,
Upper Case, Lower Case, Bookmark, Jump to Bookmark, Goto Line, etc, and so
application of Emacs keybindings would also effect the editor actions.

There would be a single, dominant set of key bindings.  This would override
the accelerators defined in an editor, where the editor contributes one of
the common actions.

For instance, if you're a java developer who is familiar with MS Interdev,
you may choose the MS Interdev key bindings.  These key bindings would work
in the java editor,as well as the Html editor.  If you're an html
developer, who is familiar with Front Page, you may choose the Front Page
bindings.  These bindings would override your html editor, as well as your
java editor.  A single set of keybindings should work everywhere, and that
set should be chosen by the user.


platform-ui-dev mailing list

platform-ui-dev mailing list

platform-ui-dev mailing list

Back to the top