[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-debug-dev] Proposal: Project filtering in the launch configuration dialog
|
Joe,
I suggest to allow working sets as filters too.
Dani
|---------+------------------------------->
| | "Joe Szurszewski" |
| | <Joe_Szurszewski@oti|
| | .com> |
| | Sent by: |
| | jdt-debug-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 08/12/2002 10:15 PM |
| | Please respond to |
| | jdt-debug-dev |
| | |
|---------+------------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: jdt-debug-dev@xxxxxxxxxxx, platform-debug-dev@xxxxxxxxxxx |
| cc: |
| Subject: [jdt-debug-dev] Proposal: Project filtering in the launch configuration dialog |
>-------------------------------------------------------------------------------------------------------------------------------|
This is a proposal for allowing 'project filtering' in the launch
configuration dialog. The primary goal is to allow users to constrain the
configurations shown in the tree on the left side of the launch
configuration dialog. This is necessary because users are reporting that
they have many configurations and no good way of looking at only a subset
of them. The proposed solution is to allow users, via a drop-down 'combo
box' widget located immediately below the current tree, to specify an
Eclipse project, thus limiting the launch configurations shown in the tree
to only those associated with the specified project. The combo box would
be labelled 'Project' and would be populated with one choice for each
Eclipse project in the workspace, plus a choice for 'Show all', which would
show all launch configurations, and a choice for 'None', which would show
only configurations that had no associated project. The project fil! ter
setting would be persisted across instances of the launch configuration
dialog.
The strength of this approach is that it does allow users to manage large
numbers of launch configurations. Given that all development in Eclipse is
project-oriented anyway, the requirement that users specify a project on
their configurations does not seem too onerous in return for the added
manageability. This is already happening in many cases with Java
Application configurations, since specifying a project is how the user
constrains the search for a main type and sets up the default values for
source location. Another strong point is that this requires very little
additional screen space in the launch configuration dialog. A weak point
is that a drop-down widget is not as flexible as say a multi-select list
that would allow users to choose multiple projects. However, such an
approach would require significantly more real esate in the launch
configuration dialog.
As for API, a few things would have to change. At the moment, the project
is a Java-specific launch configuration attribute. This would have to be
promoted to become a generic debug-level attribute for all launch
configuration types. To minimize disruption, the constant for the project
attribute could be deprecated in its Java definition, and simply be
redirected to a new definition living in the generic debug plugin. The
code that accesses this attribute currently lives in
AbstractJavaLaunchConfigurationDelegate. At present, all Java delegate
implementors extend this class. A new, langauge-independent class,
AbstractLaunchConfigurationDelegate could be created to contain the project
attribute code. AbstractJavaLaunchConfigurationDelegate would extend this
new class. This prevents breakage for any current Java delegate
implementors. Non-Java delegate implementors are either ignoring project,
in which case they may continue to safely do so, or are capturing their own
project attribute. In this case, they may continue to do so, but would not
benefit from the ability to filter by project, or they may wish to change
their delegate to extend AbstractLaunchConfigurationDelegate. In most
cases, the disruption to delegate implementors should be minimal.
All comments are welcome.
