[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Editor management improvements
|
Here's the summary of platform-ui-dev postings and bug reports in
Bugzilla (as of Sept. 10) related to editor management issues in Eclipse.
Current Mechanism in Eclipse v2.0
---------------------------------
For discussion purpose, I list the current ways one can switch between
editors in Eclipse:
- Arrows next to the tabs (when there are many opened editors)
- Ctrl+F6 or Ctrl+Shift+F6 to see a list of opened editors and
switch between them
- "Switch to editor..." menu item (Ctrl+Shift+W) to bring up the
switch to editor dialog
There are also proposed solutions:
- Editor view showing a list of opened editor (has working code)
- A drop-down list of all opened editors, via a control between
the arrows next to the tabs (no code yet)
Sample competitor's solution:
- IDEA's IntelliJ editor: primitive back-track support
via Ctrl+Shift+Left/Right
- MS VisualStudio .NET: standard window navigation support
Top Issues
----------
After analyzing the platform-ui-dev postings and bug reports in Bugzilla,
and thinking through the common editor use cases, I think the following
are the two key user scenarios for editors in an IDE:
1. Understanding Code
Users are trying to understand the program by opening editors to
browse / analyze the code. Users may open the editors explicitly (e.g. by
double-clicking on an XML file), via the search result view, using F3 to
inspect a type, and so on. There will be many editors opened in this user
scenario. In this case, users will start with an initial set of files (e.g.
two Java files and one XML file) as their (initial) working set, but it
will grow as users drilling down into the base classes, etc. However, users
won't be concerned with this expanding working set, since their main goal
is to understand the program, they will browse / analyze as much code as
required to accomplish the task. In their mind, the working set is still
the initial set of files -- two Java files and one XML file.
The second case in this user scenario is debugging. Users will use
the debugger to trace through the program flow, and have as many files
opened as required to achieve their goal -- finding the bug / problem with
their program. Their initial working set is their program code, everything
else that are opened during the program execution support the debugging
task.
For this scenario, users don't (and shouldn't) care how many editors
are opened, since they want to focus on their task -- understanding code.
They need the capability to quickly drill-down and back-track through the
program code they are browsing / analyzing.
2. Editing Code
Users are ready to focus on creating / modifying program code. They
usually have a specific working set (which includes a set of resources, not
just Java files) to deal with. They want quick access to this working set
and work with them. In this case, I think switching between opened editors
is a red-herring. Users are probably not mentally concerned if certain
files are opened or not, but they would just want to work with it (instead
of wasting time to find out if the file is opened in an existing editor,
and then switch to that particular editor).
Although the above two scenarios are separate, however I think users are
not always working in one or the other mode exclusively. There will be
times when they need to (seamlessly) transition from understanding
(scenario #1) to editing (scenario #2), and vice versa. This transition may
not be explicit or abrupt, so we need to support such transition smoothly.
Top Requirements
----------------
From the discussions above, I have identified the following top editor
management requirements in Eclipse. Note: I refer to the term "working
set" below loosely, I mean a collection of resources. However, this can be
mapped to the Eclipse working set concept nicely.
- Ability to drill down on resource / type information
- Ability to back track from drill-down operations easily
- Ability to navigate among opened editors quickly
- Ability to view and define a working set of resources,
in a single action, that users will focus on for editing purpose
- Ability to add a resource to the working set easily
- Ability to see full path file name
- Ability to apply actions (e.g. close) to opened resources that do not
belong to the user's working set (this means Eclipse needs to keep track
of
the working set boundary for opened editors)
- Ability to close multiple opened editors at once
- Ability to save contents of multiple opened editors at once
- Ability to switch between opened editors with only one hand using
accelarator keys
- Ability to distinguish opened files via editor tabs under normal
circumstances
- Ability to select all clean editors or its compliment easily
- Ability to see opened editors from all windows
- Ability to close all but the current editor
- Ability to close all editors of a given type or close all editors that
are not a given type
Jin Li
IBM Canada Ltd.
Internet: jinli@xxxxxxxxxx
"Kevin Haaland"
<Kevin_Haaland@xxxxxxx To: <platform-ui-dev@xxxxxxxxxxx>
> cc:
Sent by: Subject: [platform-ui-dev] Editor management improvements
platform-ui-dev-admin@
eclipse.org
2002-09-24 19:59
Please respond to
platform-ui-dev
How eclipse manages editors has been a good source of defect reports,
feature requests and newsgroup postings. In some cases developers
have implemented alternative editor management strategies and have
proposed that the eclipse platform team adopt it. In order to
properly assess the merits of the existing as well as proposed
strategies it would be useful if we started with a shared
understanding of the problem.
A summary of platform-ui-dev postings and bug reports in Bugzilla (as of
Sept. 10) related to editor management issues in Eclipse will be posted
soon. The purpose is to identify the issues and requirements for editor
management in eclipse so that we can use this as the reference to further
discuss and refine the top issues and requirements. If you would like
to add to or refine this analysis your feedback is welcome
In order to reach closure quickly on this I propose that we end discussion
on this by October 5'th. At this time we will use our shared understanding
of the problem to decide what enhancements, if any, are needed
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
