Community
Participate
Working Groups
The IWorkingSetManager.createWorkingSetSelectionDialog javadoc states the following: "Creates a working set selection dialog that lists all working sets with the specified ids and allows the user to add, remove and edit working sets with the specified ids. The caller is responsible for opening the dialog with IWorkingSetSelectionDialog#open, and subsequently extracting the selected working sets using IWorkingSetSelectionDialog#getSelection. Parameters: parentShell the parent shell of the working set selection dialog multi true=more than one working set can be chosen in the dialog. false=only one working set can be chosen. Multiple working sets can still be selected and removed from the list but the dialog can only be closed when a single working set is selected. workingsSetIds a list of working set ids which are valid workings sets to be selected, created, removed or edited, or null if all currently available working set types are valid " The explanation of parameter "multi" indicates that if false, you are forced to select only 1 working set in the resulting dialog in order to confirm. This is not actually true. The actual behavior is: you can always select multiple elements in the resulting dialog; the value of "multi" doesn't matter. The difference is: if multi is true, the result of IWorkingSetSelectionDialog.getSelection() will be an array of selected IWorkingSets. If multi == false, IWorkingSetSelectionDialog.getSelection() will return an array of IWorkingSets with only 1 element, which will be an aggregating working set of all selected working sets. The javadoc of WorkingSetSelectionDialog constructor should be fixed as well.
Are you suggesting that the javadoc be changed to match the behaviour or that the behavior should match the javadoc? Either way, I think we're too late for 3.4. If it's a doc change, then it's a breaking API change (effectively). If it's a code change, it's far too much work for RC2 (and who knows who we'll hose in the process). I'm going to have to defer this until 3.5
I think changing behavior would break clients relying on the buggy behavior (Mylyn, for example :), so I think it is better to just change the documentation to avoid confusion in the future. But I don't think it would be an API breaking, because the behavior stated in javadoc was never true, and the method signature and implementation remains the same. Anyway, there is no problem in making it for 3.5, since this has been there since beginning and no one noticed it.
Once upon a time it WAS true though... in the 3.1/3.2 years, before the introduction of the window working sets.
Created attachment 119382 [details] Patch 1 In changing the JavaDoc for the interface IWorkingSetManager, we assume that all the other implementations, if ANY, behave the same way as the default one.
Fix in HEAD. Thanks Hitesh!
*** Bug 126876 has been marked as a duplicate of this bug. ***
See bug 245515 for how aggregate working sets are leaked in the current implementation (with multi == false).
Verified in I20090429-0800.
