Community
Participate
Working Groups
3.3 M6 IMO, the 3 working set tool bar buttons are not solving the problems we have with working sets and I think they are not intuitive. I use this bug to summarize the ideas: The tool bar buttons try to solve 2 problems: 1.) Selecting the active window working sets 2.) Provide help to modify an existing working set For 1.), I think if a window working set is selected, this should be clearly and prominently visible in the window. My suggestion is to not have this in the tool bar but rather in the status bar: For example a combo with 'Configure' button in the lower right corner. The combo shows the sets of recently used working sets (note that a Window working set can be more than one working set). 'Configure' lets you select a new set of sets. This UI should only be there for users who use window working sets. All others should be able remove this item. For 2.) I think we should bring the functionality directly to a.) the Package explorer and Project navigator when they are in the 'Group by working set' mode: - Context menu on projects to add or remove the selected project to one or more working sets - Context menu on the Working set node to configure a working set b.) The new project wizards to automatically add the new project to one or more working sets (As already done in 'CVS > Check Out As') c.) Improve the working set configuration dialogs to avoid the big check box list and rather go in a dialog with 'Add' 'Remove' functionality. Related bugs: bug 154186 for 2c.), bug 157979 for 2a.)
1) I can explore something along those lines with our new menu placement story. It'd make a good test case. 2) a) I wanted to add this to the context menu originally but I was beaten down. However, much like 1, it might be possible to do something with the new menu placement. If we tie visibility to action set enablement we should satisfy those who are afraid of context bloat. b) good idea, but I dont know if we'll have time in 3.3. People have been asking for this for ages. c) again, not sure there's enough time for this in 3.3. Also, we've had a lot of negative feedback regarding those two-tree add/remove lists in the past. Kevin, you've had concerns about this action set in the past. In what ways do you think we could improve it?
Note that my suggestion is to add the context menus only at specific places: Project/Package explorer in working set group mode on projects. I believe that's where users need the action. Of course to add such actions as Object contributions is out of discussion. Also note that 2a. and 2b. are of course things that we would implement in JDT (if we agree that this is the way to go)
I've been thinking about 1) a bit more and I'm not sure we want to introduce window working sets as named/identified collections. I dont think having a combo full of lists of working sets (or explicitly named sets of working sets) helps clarify the purpose of window working sets in any way. In the future, with the right API, we could possibly bring attention to which views are currently showing the window set. A control that would easily allow you to set which views are currently using working sets would be very handy. I'll continue investigating but if you have any specific workflows you'd like this new combo to expose I'd appreciate it.
Naming sets of working sets wasn't in my mind either. But as the current design is that a window working set (WWS) can also be more than one working set (WS), we wanted to come up with a compatible solution. I assume that most users just have one WS in their WWS. But typically users need a quick way to switch between different WS as WWS. So a combo with the history of sets is of good use here, you don't want to deselect the old one and select new one again and again from a big list. To add the functionality from 2.) to the package explorer we have the following bugs in JDT/UI: bug 182100 for 2a), bug 150009 for 2b) and bug 154186 for 2c.) We're trying to implement them for this polish pass so we can offer good alternatives for the tool bar buttons that go away. Speak up if you disagree. We had some more discussion about 2b.) (UI in the new Java project wizard to specify WSets) and we would like to suggest that we reconsider the decision taken in the status meeting. As CVS already has it and it's good functionality, we would like to take the opportunity. I'll write a separate mail for that issue to you and McQ.
Martin: aha! I get what you're talking about now. Hmm. Yeah, that could be useful...
Random idea: From a navigation point of view I think my ideal would be that each Project/Package explorer/navigator would clearly show which working set it was showing, say as a dropdown in the view toolbar. Then I would use multiple view instances, each with a different working set (or one with none for global navigation). Maybe titles of the views reflect the working sets (we forgo the normal titles under the assumption that the view icons carry enough info for identification). This way, I have a clear jumping off point for each working set and its evident when I am in one context or another. Switching between working sets then becomes a matter of switching views (very easy). I recognize thought that we support multiple WS which changes a bit how we present them although I am guessing that the 90% case is a single one. Similarly, I may set it at the level of the workbench window with clear feedback (say in the title bar) that that's the context. Mixing window and package level working sets in the same window seems confusing though. (Note: I see we have this notion of WWS but I actually don't understand how to configure their contents, I only seem to be able to sometimes choose them). Its not that we should have WS vs. WWS, just a single notion with different levels of scope, so in theory: Workspace(no WS) [*1] Workbench <-> Working Set(s) Window <-> Working Set(s) Perspective <-> Working Set(s) [*2] View <-> Working Set(s) *1 choose per workspace level operation such as we do now for search *2 since views are shared across perspectives this could be tricky/bad idea Either setting a WS at a given scope prevents setting at an inner (so having a Window WS precludes a View WS in that same window), or inner scopes can refine larger (so if WWS is three projects then VWS can chose from those three). Probably former is easier to explain and implement.
Kevin, can we keep this bug to discuss about how to polish and fix the current functionality of WSS and WS configuration? It would be better to file a new bug for new ideas.
You're right of course. I find sometimes random ideas are helpful for dislodging a mental log jam but in this case perhaps not :) But if we thought that there was inherent problems in the way we're associating WS with views and operations that'd tell us what we might and might not be able to do now. For me, there's something "just not quite right" about how we handle WS and until I figure out what that is its hard for me to be helpful.
I've run out of time to explore this issue further. Issues relating to the presentation of widgets in menus has occupied the most of the time and all I've really got done is a skeleton. Given that the idea is unproven and there are still some critical things to be done with the menu system I'm going to defer any more work on this until after 3.3 ships.
Agreed. We need to fix the critical holes before we can do polish.
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.
