Community
Participate
Working Groups
I20060918-2000 If you set the Project Explorer to use working sets as top level elements the working set menu items (Select Working Set, Deselect Working Set, and Edit Working Set) become confusing. Although the standard working set dialog does appear to work it's not at all clear that you're selecting a list of working sets to show. The package explorer provides its own dialog for this purpose. If you feel that we should be providing this dialog for all clients please open a new PR against platform-UI.
What if the default dialog displayed a "Show as groups" checkbox?
I dont think that would be applicable across the board - most viewers aren't configured to show working sets as elements. That also doesn't address the additional menu items - deselect and edit are useless in this scenario.
I vote for using the dialog from the Package Explorer. The reason is that it also allows custom sorting of Working Sets which the default dialog doesn't provide. There is also another usability issue. If you select Working Sets as top level elements the first time and no Working Sets are selected than ALL should be visible instead of an empty view. (3.3 M5) Maybe there should be a warning that no Working Sets are selected and the view will be empty.
The behavior that Gunnar refers to has been fixed (showing all when no working sets are supported, but still exists for Window working sets - bug 190819) Martin -- what are your thoughts on contributing the Working Set dialog to Platform?
Yes, I think it would be good to have the working set selection dialog in platform as well. Platform already has a selection dialog, but it is more targeted to select a working set filter: You can choose 'Window working set' and 'No Working Set', which make no sense in our scenario. So we could think of making the existing dialog more configurable. Important is also that the selection dialog we need filters out some working sets (we only want Java and Resource working sets), and allows the artificial 'Other Projects' node. So in the end it might be easier if you reimplement the dialog as there are so many special requirements here.
Not for 3.4.
Kim, is this still an issue? The package explorer and project explorer have identical dialogs for this now. It does not seem confusing to me after the other working set bugs have been fixed (the omnibus working set bug 212389).
(In reply to comment #7) > Kim, is this still an issue? The package explorer and project explorer have > identical dialogs for this now. It does not seem confusing to me after the > other working set bugs have been fixed (the omnibus working set bug 212389). > This is still an issue. When the project explorer is in working set mode the menu items still appear.
(In reply to comment #8) > This is still an issue. When the project explorer is in working set mode the > menu items still appear. > Yes, I agree that they appear, but I'm not confused by them. I mean it seems that you should be able to select or edit working sets even if the top level objects are working sets, so I don't understand the confusion. Can you help me here?
(In reply to comment #9) > (In reply to comment #8) > > > This is still an issue. When the project explorer is in working set mode the > > menu items still appear. > > > Yes, I agree that they appear, but I'm not confused by them. I mean it seems > that you should be able to select or edit working sets even if the top level > objects are working sets, so I don't understand the confusion. Can you help me > here? > They just dont make sense... if the top level elements are working sets, it's not a matter of selecting a working set, or even a composite working set, it's a matter of selecting N different working sets. Similarly, "deselect" working set doesn't make any sense. "Edit" might, but even that's debatable. This mode of work really does benefit from a specialized dialog such as the one JDT offers - "Configure Working Sets"
I get it now, sorry for being so thick. If it behaved as the Package Explorer then it would make more sense. I will make it so.
Francis, I agree with Kim and I don't see it as an enhancement.
Created attachment 161472 [details] Patch to move copy the workspace selection dialog into platform UI This is copied from the Java version and the Java-specific stuff was removed, but parameterized so that later JDT should be able to hook up to it.
Created attachment 161473 [details] Some work - copying ConfigureWorkingsetAction Does not compile, just saving it here.
Created attachment 166015 [details] Work in progress Not ready yet, just saving it here.
Close, but not going to make it this time around. Look for this in 3.7.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug has been marked with as "stalebug" for some time now. I mark this bug as "worksforme" to indicate that no work is planned here. If this bug is still relevant for the latest release, please reopen the bug and remote the "stalebug" whiteboard tag.
