[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Proposal: Project filtering in the launch configuration dialog
|
While development in ECLIPSE using Java and many other languages is
project-oriented, for some
remote platforms (for example iSeries), project concept is 'sort of'
optional. That is, iSeries has the
'Remote System Explorer' (RSE), which is a 'filtered' view of the iSeries
server. In itself, RSE is one
giant project, but it is not really exposed to the end users in such a way.
Of course, we define ore re-use
a concept of an iSeries project for various languages as well, but at first
our customers are more likely to
use RSE in order to get their hands into the ECLIPSE platform.
Therefore, I think allowing 'project filtering' in the launch
configurations dialog is far too restrictive. I believe
that "working sets" might give more flexibility, but I would like to better
understand the definition of the
working set in the context of the launch configuration dialog.
As for the API changes: I would actually encourage promoting selected
project to the generic debug-
level attribute for all launch configuration types, as long as it could be
ignored if required.
Since we talk about launch configuration filtering, I have another request,
or maybe I need to be pointed to
an existing API :-)
I am wondering, if we can define some kind of hierarchy of launch
configuration types in the launch configuration
tree. That is if I have a few launch configuration types related to say
iSeries, whether I can create a single
'iSeries' node in the tree and put all iSeries related launch configuration
types under that node. I suppose we
should be able to specify this somehow in our plugin.xml. Such enhancement
should also cleanup the launch
configuration tree for products that support more then just Java...
Any thoughts?
Thanks,
Vadim Berestetsky
Distributed Debugger Development
Internet: berestet@xxxxxxxxxx
|---------+------------------------------------>
| | "Joe Szurszewski" |
| | <Joe_Szurszewski@xxxxxxx>|
| | Sent by: |
| | platform-debug-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 08/12/2002 04:58 PM |
| | Please respond to |
| | platform-debug-dev |
| | |
|---------+------------------------------------>
>------------------------------------------------------------------------------------------------------|
| |
| To: platform-debug-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-debug-dev] Proposal: Project filtering in the launch configuration |
| dialog |
| |
| |
>------------------------------------------------------------------------------------------------------|
I will investigate.
"Darin Wright"
<Darin_Wright@xxxxxxx> To:
Sent by: platform-debug-dev@xxxxxxxxxxx
platform-debug-dev-admi cc:
n@xxxxxxxxxxx Subject: Re:
[platform-debug-dev] Proposal: Project
filtering in the launch configuration dialog
08/12/2002 03:31 PM
Please respond to
platform-debug-dev
Is there some way that we could use "working sets" instead of "projects".
This would "play" better with the platform, and provide more flexibility.
Darin
"Joe Szurszewski"
<Joe_Szurszewski@xxxxxxx To: jdt-debug-dev@xxxxxxxxxxx,
> platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin Subject: [platform-debug-dev]
@eclipse.org Proposal: Project filtering in the launch
configuration dialog
08/12/2002 03:15 PM
Please respond to
platform-debug-dev
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 persist! ! ed 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 continu! e 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.
