RE: [platform-ui-dev] Editors view feature or defect (?)

[Randy Hudson <hudsonr@xxxxxxxxxx>]

Control+F6 is THE WAY to cycle documents in an MDI application on Windows.

TAB and Control+TAB should be considered the same in most cases.  They are already used to change focus among Controls.  For example, if a Control uses the TAB key to mean insert a TAB in some text, then control Tab is supposed to give keyboard users another way to say "no, really, I want to change focus".  This is what you are seing with the current Control+TAB.

But, in some cases Microsoft does use Control+TAB to mean "flip pages" on a TabPane.  In this sense, you might argue that it could switch editors, because Editors are presented in something like a TabPane.  But, what if the Editor itself is a TabPane, and already wants to use control+Tab to flip its pages?

The workbench already encroaches too much on potential acclerators that Editors might use (For example Ctrl+B for bold text).  I think they are doing the right thing by sticking to well known standard in these cases.

"Alan Oursland" <alan@xxxxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 09/10/2002 02:55 AM Please respond to platform-ui-dev

To:        <platform-ui-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [platform-ui-dev] Editors view feature or defect (?)

Just thought I would add my two cents here. Sorry if it has already been
covered.

MSDev studio used Ctrl-Tab and Ctrl-Shift-Tab to move between open
documents. It keeps a most recently used stack like the Ctrl-F6 does in
Eclipse (and Alt-Tab does in Windows). I see these hotkeys as a
generalization of the following rules:
                 - F4 closes things. Alt-F4 closes applications. Ctrl-F4 closes documents
                 - Tab moves between things. Alt-Tab moves between applications. Ctrl-Tab
moves between documents.
For some reason MS-Office uses the Ctrl-F6 to move between documents, which
is what Eclipse seems to have copied.
Eclipse does use Ctrl-Tab to switch between things -- it just switches
between views instead of documents.

Personally, I use the keyboard to navigate between documents more than I
navigate views.

Ctrl, Shift, and Tab are generally close together and can be hit with one
hand.

Alan Oursland

> -----Original Message-----
> From: platform-ui-dev-admin@xxxxxxxxxxx
> [mailto:platform-ui-dev-admin@xxxxxxxxxxx]On Behalf Of Jared Burns
> Sent: Monday, September 09, 2002 5:16 PM
> To: platform-ui-dev@xxxxxxxxxxx
> Subject: Re: [platform-ui-dev] Editors view feature or defect (?)
>
>
> > Are you telling us that you use alt+forward/alt+back with one hand only?
>
> Aherm. I use a perverted (/awesome) keyboard which happens to let
> me reach
> alt+left/right with my left hand. Sometimes I forget that the keys I can
> reach are not necessarily the keys everyone else can reach. Sorry
> about that.
> :) For the record, I can't reach alt+F6 with one hand on any keyboard.
>
> > We are thinking about the bug 5700 which I think would fix the problem:
> > "there's a place for the buttons." Do you agree?
>
> Bug 5700 is an interesting problem and I really can't comment on
> the buttons
> without knowing what you have in mind as the solution. After
> looking at the
> APIs available to solve this problem (or lack thereof), I'm
> starting to think
> that we should just solve the JDT problem. That is, we should
> just provide a
> mechanism to go "back" from F3 (Shift+F3?) or at most, a
> mechanism that ties
> into F3 and the outliner in which case the buttons might make
> more sense on
> the outliner toolbar.
>
> The only other comment I have on the buttons is that I was
> thinking of making
> the buttons function like most web-browser history buttons. Just
> clicking the
> button takes you back/forward, but there would be a cheval (sp?)
> connected to
> the button that you could pull down to select from the entire history.
> Depending on your perspective, this would be a step in the right or wrong
> direction toward resolving the redundancy between the F6 pop-up
> and the view.
>
> > I agree with promoting closeEditors(ref,boolean) to API. The
> idea is that
> > the views such as Navigator, Bookmark and now EditorsList should be
> > implemented using API only. Even though the are in the same plugin they
> > are thought as separated.
>
> I strongly support the API-only approach, so that's good news.
>
> > ... Maybe we could promote the
> > getReference(IEditorPart) so you would not have to use getPane(..)
> > anymore.
>
> That would make me happy. For interested parties, this is covered in Bug
> 22317.
>
> - Jared
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev


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