Difference between revisions of "CDT/Archive/designs/workingSets"

Revision as of 12:50, 21 April 2009

This document proposes an enhanced (considerably re-worked, actually) dialog for Working Set Configurations. I would like to contribute a patch for the 6.0 release, before M7.

Working Set Configurations

CDT 5.0 provides support for working-set configurations. These provide a means to easily change the active build configurations of the C/C++ projects in a working set to some consistent selection. The current UI has a number of deficiencies of usability and function, and is not extensible to handle rich build-configuration models such as may be defined by custom project natures (usually derived from the C nature).

Current state of the art

The current working-set configuration support contributes a Configs for Working set action to the Build Configurations sub-menu of the Project menu. Invoking this action brings up the following dialog:

This dialog has several functional and usability problems:

• redundant use of the words "config set" in the buttons (and truncation of the word "configuration")
• the Update config set button is required to make changes to configuration selections "stick." Without it, changing a configuration set, selecting another, then returning to the first loses the changes. Even pressing the OK button doesn't persist pending changes
• the -- CURRENT -- configuration set looks like a real configuration set, but it is just a proxy for the line-up of active configurations for the projects. Its relationship to user-defined configuration sets is confusing, especially as it is editable but not persistable
• the Save, Build and Exit button is very confusing. What does it build? Why does it close the dialog? What does it save?
• the serialization of configuration sets is in a plain-text format with spaces to delimit fields. This breaks when working sets, projects, and build configurations have spaces in their names.
• the dialog only handles the basic CDT notion of a project build configuration. It doesn't provide any API to extend it for derived project types, which may define multiple orthogonal dimensions (e.g., debug/release and target platform dimensions). Moreover, some of these dimensions of configuration may permit multiple selections per project

Proposed new UI

The menu action would be renamed to Working Set Configurations... (note the ellipsis indicating a dialog) and the dialog reworked to look like this:

To address specifically the problems with the current dialog:

• the word "configuration" is used in its entirety and the buttons use standard labeling convention
• changes to project configuration selections "stick" in the dialog without needing to press an update button. The OK button closes the dialog and persists the changes to the preference store. The Cancel button closes without saving
• the labels in the Working set configurations pane clearly indicate which working set is active.
  • A working-set configuration is active if and only if for all of the projects in the working set, their active configurations are as specified by the working set configuration
  • If the the currently active configurations of the projects in a working set do not actually correspond to any of the presets shown in the dialog, then a special configuration is presented (with an italic font) so that the user can see what the current settings are. This special configuration cannot be modified, as it reflects exactly the reality of the workspace. When some other configuration is activated (via the Set Active button, see below), then this special configuration is no longer shown
• the Set Active button (so labeled for consistency with other buttons and menus in CDT) applies the selected working-set configuration to the projects in the workspace. There is no explicit action to build anything. When the user presses OK to save changes to the configurations, if any configuration was applied that changed any project's active configuration setting in the workspace, then the user is prompted to build the affected projects (even if Build Automatically is enabled, because it does not trigger a build on project configuration changes)
• serialization will use an XML-formatted string (using IMemento) instead of plain text with space and form-feed delimiters. For backward compatibility, the old format can be read by the new dialog
• the dialog will expose an API on the working-set configuration model that custom project natures can contribute to and extend to implement custom configuration selections. This API is TBD and would be internal/provisional, as we are now past API Freeze

Building Working Set Configurations

TBD

Data Model and Extensibility

TBD

References

For traceability, this proposal is cross-referenced to bugzilla:

• Bug 272416