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

[Jared Burns <jared-eclipse@xxxxxxxxx>]

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