Re: [platform-ui-dev] Re: [Editor Mgmt] Make EditorManager$Editor adapta

["Joe Szurszewski" <Joe_Szurszewski@xxxxxxx>]

Well, if having the editor drop-down being maximized only in the editor area is too restrictive, it seems that some sort of editor view is the best solution.  

It just seems to me that if the main concerns are:

- Want to see full names of edited resources (or at least enough to distinguish one from another regardless of the number of open editors)
- Want to multi-select editors to perform operations (such as Close) on them
- Don't want editor selection area to be tied to just the editor area
- Want to minimize clicks required to navigate editors
- Want to minimize screen space required for editor navigation

then, some sort of editor view addresses the first four pretty directly.  An editor view IS a concern with respect to the screen space issue.  One way to soften this impact might be to replace the tabs with the drop-down as suggested, but have some sort of button near the drop-down, or some sort of gesture in the drop-down area that shows/hides the editor view.  Putting the editor view on fast view is another option.  This way, users who don't want to waste the space required for the editor view can quickly bring it up when required, and just as quickly hide it.  Or they can choose to navigate editors strictly through the drop-down, and completely ignore the editor view.

Joe

"Nick Edgar" <Nick_Edgar@xxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 10/25/2002 01:41 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] Re: [Editor Mgmt] Make EditorManager$Editor adaptable

By the 'editors dialog', I mean the one you get when you choose Window > 
Switch to Editor...  or Ctrl+Shift+W.
The dialog is actually titled 'Switch to Editor', but it lets you do more 
than just switch (save, close, etc).

Jared was saying that the editors view is usually docked on the left, 
above or below the outline view.  Jared, did you really mean outline, 
which is normally on the right, or navigator/packages view?
In any case, having an editor drop-down be maximized only in the editor 
area may be too restrictive.

Nick





"Joe Szurszewski" <Joe_Szurszewski@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
10/25/02 12:41 PM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-ui-dev] Re: [Editor Mgmt] Make EditorManager$Editor 
adaptable



Nick, 

When you say 'editor switcher', I assume you mean Ctrl-F6.  What is the 
'editors dialog'?  I can't find such a thing. 

I like something similar to the idea of pinning the drop down.  The 
drop-down could appear by default, and a single click would activate the 
selected editor.  The user could 'maximize' the drop-down, and it would 
look much like Jared's editor view.  It could have all the functionality 
you mentioned, sort options, multi-select, etc.,  When maximized, the user 
can drag the sash to control the amount of height it gets relative to the 
editors.  When minimized, (drop-down mode), it is always a single line 
high.   

Doing this minimizes the number of clicks required when doing real work, 
i.e., it's always just one click to select an editor whether in minimized 
or maximized mode.  I agree that having two modes is not a perfect 
solution, but I think it's the best compromise of screen real esate and 
functionality concerns.  I think this scales a lot better than the tabs, 
even if they get a couple characters back and scrunchiness factor can be 
controlled. 

Joe 





"Nick Edgar" <Nick_Edgar@xxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx 
10/25/2002 10:42 AM 
Please respond to platform-ui-dev 
        
        To:        platform-ui-dev@xxxxxxxxxxx 
        cc:         
        Subject:        Re: [platform-ui-dev] Re: [Editor Mgmt] Make 
EditorManager$Editor adaptable


Joe,

Note that this is currently supported in the editors dialog. I realize 
that this is more out of the way than Jared's view, but it's there 
currently.

One issue I have for doing this in a drop-down is how to support 
multi-select while not costing too many mouse clicks (or other gestures) 
for the basic editor activation case.
I see two basic possibilities:

1. Single-click activates but does not dismiss the drop-down. Double-click 

would dismiss as well.  This means more double-clicks though, which many 
people complain about.
We could make it honour the preference for single-click/double-click, but 
this takes effect everywhere.  I'd like it to work well for the default 
preference of double-click.

2. Allow the drop-down to be pinned.  Normally single-click activates the 
editor and dismisses the drop-down, but if pinned you could to do 
multi-select and close all etc.
But this introduces an extra mode, which I don't like.

I'm open to other ideas.

Nick





"Joe Szurszewski" <Joe_Szurszewski@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
10/25/02 10:50 AM
Please respond to platform-ui-dev


       To:     platform-ui-dev@xxxxxxxxxxx
       cc: 
       Subject:        Re: [platform-ui-dev] Re: [Editor Mgmt] Make 
EditorManager$Editor 
adaptable



Nick, 

As a heavy user of Jared's editor view, I'd be interested in evaluating 
any improvements you make in this area.  I think the ability to close 
multiple editors is particularly useful, and would like to see a similar 
feature in whatever the UI team comes up with. 

Joe 





"Nick Edgar" <Nick_Edgar@xxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx 
10/25/2002 09:01 AM 
Please respond to platform-ui-dev 
 
       To:        platform-ui-dev@xxxxxxxxxxx 
       cc: 
       Subject:        [platform-ui-dev] Re: [Editor Mgmt] Make 
EditorManager$Editor adaptable



Jared,

Thanks for forwarding these.  I've been going through this thread and
others from September to revisit the editor management problem.
We are committed to making improvements here for M3.

I like what you've done with your view.  In particular, the working set
support looks cool, although I haven't used it in serious development yet.
Have you gotten much feedback about this feature?
I also appreciate you accurately summarizing the known problems with the
current support and pointing out how your view meets many of the criteria
that Jin outlined.

However, I don't think that simply releasing your view in the platform is
the right answer, for the following reasons:
1. It is extra UI over what we currently have, leading to multiple ways of
doing the same thing, causing confusion for the user.  Instead, we should
acknowledge that what we have is broken in several respects, and fix it.
2. A view takes extra screen real-estate (have you gotten much feedback
about this, whether it's a problem, and how people position it?)
3. It's not easily accessible for keyboard-only users -- you have to use
the Ctrl+F7 view switcher to get to it (actually, Enter doesn't seem to
work to activate the selection currently).
4. We need to be careful about introducing extra dependencies on Core
Resources in the Workbench proper.  It's fine to do so in the standard
components (Navigator etc.) but not in the basic editor management 
support.

What we're thinking of doing for M3 is:
- make some improvements to basic editor tabs:
- get rid of the ... in favour of a couple of extra characters in the
name, and just let it clip
- make the scrunchiness factor adjustable in the prefs
- consider getting rid of the icon in favour of more space for the name
- provide a drop-down that takes the best from the editor switcher, the
editors dialog, and your view, and get rid of the others
  - keep at least activate / save / close / close all functionality
  - possibly working sets too, although we need to be careful about
dependencies on core resources
  - allow multiple sort orders for the items (MRU, alphabetical order,
tab order)
- give it an accelerator usable with one hand (e.g. steal Ctrl+E from the
editor and find some other accelerator for delete-line)
- if the drop-down is really effective, we may abandon the editor tabs
entirely in favour of showing the full file name

One disadvantage of a drop-down is that it will require at least one more
click to use than your view, and possible two more for simple editor
switching (click to drop it down, select an editor to activate it, click
elsewhere to dismiss the drop-down (or double-click on the selection)). We
could look into doing something funky like letting it be torn off as a 
view
(a regular view or fast view, not a detached view, although we're looking
at that again too). If the user has control of the screen real-estate, and
there aren't multiple inconsistent UIs, I don't mind having it appear in
two possible places.  If you have any other ideas here, I'd love to hear
them.

I do apologize if you were given the impression that we were going to
simply release your view as-is.  All along I've been hoping to learn from
your and others' experience with your view, and take ideas from it, if not
the implementation.  It's just taken longer than any of us would like, for
various reasons.
Hopefully you'll be able to continue working with us on improving basic
editor management.  It would be great if you and possibly others in MIN
could do early evaluations of the work we'll be doing for M3.

Regards,
Nick




 
                    Jared Burns 
                    <jared-eclipse@mn        To:       nick_edgar@xxxxxxx 

                    .rr.com>                 cc: 
                                             Subject:  Fwd: Re: 
[platform-ui-dev] [Editor Mgmt] Make EditorManager$Editor adaptable 
                    10/24/2002 12:08 
                    PM 
 
 




Here's an earlier email that I sent to the platform-ui list in response to
a
question from Eduardo. Again, the entire discussion can be found on the
platform-ui-dev archive. I started this thread with a message sent on
9/6/02
titled "[Editor Mgmt] Make EditorManager$Editor adaptable".

- Jared

----------  Forwarded Message  ----------

Subject: Re: [platform-ui-dev] [Editor Mgmt] Make EditorManager$Editor
adaptable
Date: Fri, 6 Sep 2002 16:46:49 -0500
From: Jared Burns <jared-eclipse@xxxxxxxxx>
To: eduardo_pereira@xxxxxxx
Cc: platform-ui-dev@xxxxxxxxxxx

On Friday 06 September 2002 01:20 pm, you wrote:
>
>         Please if you have the time, could you list all feature you have
> in your view, explain me why do we need a view, why isn't the editors
> dialog enough? By having a view, could we remove the editors TABs?
>
> Eduardo.

The editors dialog isn't enough because of its transient nature. It is
tedious to have to summon a pop-up window and select an item in a menu
everytime I want to switch editors. Also, Ctrl+F6/Shift+Ctrl+F6 are
inconvenient shortcuts - it takes both hands for me to hit Ctrl and F6
together. 

I originally implemented this view because the tabs are suboptimal.
Problem #1: Name cropping.
When I'm working on the debugger, I very often have files like
JDIDebugTarget, JDIDebugElement, and JDIDebugModel open at the same time.
When the tabs for these three editors all say "JDIDebug...", I'm stuck
guessing which tab is which. Even files without common prefixes are
difficult
to find when they're cropped because they require extra computation on my
part. If I'm looking for the "JavaHotCodeReplaceManager", it takes a 
little

mind warping to see success in the editor tab which reads "JavaH..."

Problem #2: Tab scrolling (or: The Dreaded <  > Buttons):
I'm a many-editor kind of guy (more on that later). If I'm browsing in my
12th editor and I decide that I want to glance at the 3rd editor quickly,
using the scroll buttons is torturous. *click (to scroll)* *read (to see 
if

my editor is now visible)* *click* *read* *click* *read*. I suspect that
the
tab scrolling buttons are there to partially address Problem #1, but the
buttons do not scale to more than a few extra editors.

Problem #3: Cannot close multiple editors at once
Closing multiple editors (not ALL editors) at once via the tabs is painful
because the location of the close button (X) is unpredictable. When I 
close
a
tab M, tab L often shifts a bit such that I cannot quickly close tab M,
then
tab L. I have to close tab M, wait for the tabs to shift, and then close
tab
L from its new location. Even without the shifting problem, it is very
tedious to close more than 3 editors (click, click, click, click,...).

The many file rant:
Why do I ever have 10+ files open at a time? Because when I'm browsing
code,
particularly in new territory, I don't want to be bothered by editor tab
maintenance. I just want to keep browsing like there's no tomorrow. For me
to
keep the number of open editors low, every time I open an editor I'd have
to
look back at my other editors and ask, "Now which one of these editors do 
I

think I won't need again?" When I'm trying to understand a problem, I want
to
stay focused on the problem. Distractions like this hurt my productivity.

The editor list solves these problems.
1. Because it presents the editors in a list view, the editor titles are
always the same width, so I can always read the file names. 
2. Because it presents the editors in a list view, scrolling through the
list
of editors is fast and simple. Switching from editor 12 to editor 3 is as
simple as clicking on the 3rd item in the list or, at worst, scrolling to
the
top and then clicking the 3rd item in the list.
3. The editor list allows you to multi-select editors and close them. This
feature is great for browsing code and then cleaning up the editors you
left
behind. I can be editing class A and go off browsing classes B through M,
not
being bothered to clean up after myself as I go. Then, when I'm done
browsing, I can shift-click to select editors B - M, right click -> close.

In addition to solving the problems I found with the tabbed interface, 
I've

also added a couple new features in the editor list which I find useful.
Most
importantly, I've added the ability to create working sets on the fly. 
This

is achieved by multiselecting some editors, right click -> Create working
set
-> Enter a name in the dialog. This interface encourages you to create
natural working sets based on the files you're using to solve a problem. 
Of

course, the view also allows you to open these working sets. This
effectively
allows you to take a snapshot of your current editor state and come back 
to

it later. If you're in the middle of working on a problem and you need to
switch to something else, you can quickly create a working set with your
open
editors. When you want to come back to the problem, you just open that
working set and "viola," you're back where you were.

Also, once Bug 23032 is addressed, the view will support the Team menus 
(it

already does in my local workspace). This feature, combined with the
working
set feature, makes editing non-Java resources simpler. A specific use-case
I
have is maintaining build notes. When I'm doing normal Java development, I
open files through the "Open Type" dialog and synchronize with CVS via the
Outliner. However, when I want to update the build notes (which I do 
almost

daily), I have to go digging in the packages view to open the file and 
then

find the file in the view again when I'm ready to synchronize. With the
editor view, I just created a "Build notes" working set that I can open
directly from the editor view (no packages view digging) and when I've 
made

my edits, I can right click directly on the editor in the view and
synchronize from there as I would normally do in the Outliner for Java
elements.

In summary, I feel that the editor view both solves the problems with the
editor tab solution and adds new value which makes editing files more
convenient.

- 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




_______________________________________________
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