Community
Participate
Working Groups
CDT 5.0.2, 6.0 M7 The CDT provides support for defining build configurations of working sets, in the "Configs for working sets" action in the "Project -> Build Configurations" menu. This is very useful. However, the user interface for these configurations is awkward: - the "-- CURRENT --" configuration looks like a normal configuration. It would be more intuitive to simply put a check-mark in the list to make and indicate the selection (as in the project configuration selection on the right side of the dialog) - the "Update config set" button must be pressed in order to persist changes. Simply closing the dialog with the "Close" button should do the same - the words "config set" are redundant in every button - "Apply" should be used instead of "Update" - the "Save, Build, and Exit" button is confusing. It isn't clear what it saves, nor why it closes the dialog I elaborate further in the design doc referenced in this bug's URL, with a proposal for a new dialog that I would like to contribute. I invite comment on this proposal on the wiki page's discussion page.
Created attachment 132680 [details] New working set configs dialog and build menu Attached a patch implementing: - the new Manage Working Set Configurations dialog - the dynamic "build working set configuration" menu as described in today's update of the Wiki document linked by this bug's URL. Please, review both the document and the patch, and consider adopting it for this release. I understand that M7 is fast approaching ... I will respond promptly to any comments or requests for alteration. Thanks! A few noteworthy points for consideration: - the patch has all new API in internal packages, as it is now past M6 and there is no time to "soak" the API to test it with ISVs for suitability. Nonetheless, I think the UI based on the new API is useful - extension points cannot really be flagged as "internal." The description of the new org.eclipse.cdt.ui.workingSetConfigurations point does clearly indicate, though, that it is intended to be internal in this release. Besides, I see from the host plug-in's build.properties that none of the schema files are included in the SDK build, so they might actually *all* be considered internal ;-) - in order to implement dynamic menu contributions, the cleanest solution (with the least possible nesting of menus) uses the org.eclipse.ui.menus extension point. This point supports legacy action contributions, but it cannot contribute to legacy menu definitions. Therefore, it was necessary to convert the definition of the "Project -> Build Configurations" menu to the newer extension point. It seems to be compatible (all of the expected menu contents appear, and turning the action set on and off in the "Configure Perspective..." dialog has the expected results). I will happily look for another solution if this change is not acceptable - I tried to preserve as many externalized strings as possible, but in the end, only two remain from the former dialog. The UI changes required are simply too extensive to do otherwise - I tested the patch with a variety of different kinds of working sets combining these dimensions: - C/C++ working sets and Resource working sets - managed-make and custom-make projects - working sets including non-CDT projects - working sets including non-project resources - working sets comprising *only* non-project resources and also loading the initial working set configurations from the preference-string storage of the CDT 5.0 dialog
Created attachment 132936 [details] Updates to add menus and property page to working sets Attached an update with the following enhancements from off-line feed-back: - Add (active) decoration to active project configuration in the Projects Configurations tree - Sort working set configurationss in the menus - Set project node checked state greyed to indicate that they are not selectable items (as well as can be done in a tree control. It would have been nice to be able to suppress the check boxes on the top-level nodes) - on dialog open, select first child node of a working set so that we can see the projects that it contains (selecting the working set is not useful) - added a Build button to the dialog, that builds without activating the selected working set configuration - replaced the dynamic working set sub-menus in the "Project -> Build Configurations" menu with "Set Active by Working Set" and "Build by Working Set" sub-menus, to make it clear what the menus actually do, and to add the missing activation capability - heuristically make initial project configuration selections for new working set configurations by matching the working set configuration name to the project configuration names. This makes it easier to create working set configurations for the conventional Debug and Release variants - contribute a "C/C++ Build" property page to working sets for the management of the configurations of the selected working set. Re-uses the same block of controls as the dialog - add "Build" and "Set Active" menus to working sets in Project Explorer - added mnemonics for menus, including ordinal numbers for the dynamically-populated working set and configuration names - defined a property tester for working sets, with so far one property: "hasCProjects". Use to filter menu and property page contributions to relevant working sets
Good job! Now it suddenly a lot more usefull a) It is accessible (in property page) b) It is straight forward (build configuration menu contribution for working set) I am going to commit it unless somebody has any concerns
-assigned to me
patch applied to head, thanks Do we need to update docs too? It is probably not documented anyway...
(In reply to comment #5) > patch applied to head, thanks Thank *you*! > Do we need to update docs too? It is probably not documented anyway... I had thought of that, but didn't find any existing documentation for the old dialog. Actually, much of the documentation is quite out of date (especially the screenshots). I'd be happy to contribute docs. It might help people to discover these new features. I'll raise a separate doc bug, for that, if I find that I have the resources to do it.
ok thanks
Created attachment 133153 [details] Small increment for mutability of a read-only API Attached a patch with a small update to the API. An interface that is supposed to be immutable has a misplaced setter operation. The patch moves it to the mutable working-copy ("snapshot") interface.
Reopening for the API fix in the latest patch. Best to fix it now, while we can ...
patch applied
