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

Revision as of 14:10, 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 Manage Working Sets... (note the ellipsis indicating a dialog. I would have liked Manage Working Set Configurations..., but it seems to be too long; GNOME, at least, truncates it) 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 described below and would be internal/provisional, as we are now past API Freeze

Building Working Set Configurations

The Eclipse workbench keeps track of recently used working sets. In the CDT context, a working set is "used" when its configurations are edited and/or set active.

For quick access to building the project configurations specified by a working set configuration, the configurations for the recent working sets are presented in the Build Configurations sub-menu of the Project menu:

Here, we see four recent working sets (in order from most to least recently used) with sub-menus permitting selection of a configuration to build. For working sets that do not define any configurations, they do not show a sub-menu, but can be selected to build whatever configurations are current for the contained projects (an example is the Unmanaged Stuff item).

For the common case of CDT projects that are built by the MBS builder (even if they don't generate makefiles and use an external make tool), the project configurations specified in the working set configuration can be built without having to set them active. In case a project nature does not support building non-active configurations, the working set's select configuration for the project will first be applied, then the project built.

Data Model and Extensibility

TBD

References

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

• Bug 272416