Re: [platform-debug-dev] Proposal: Project filtering in the launch confi

["Darin Wright" <Darin_Wright@xxxxxxx>]

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> Sent by: platform-debug-dev-admin@xxxxxxxxxxx 08/12/2002 03:15 PM Please respond to platform-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx, platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-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 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 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.