[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-ui-dev] [Editor Mgmt] Make EditorManager$Editor adaptable
|
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