Summary: | [WorkingSets] Replace the working set toolbar buttons with a better solution | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Martin Aeschlimann <martinae> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | bpasero, Kevin_McGuire, mik.kersten |
Version: | 3.3 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Martin Aeschlimann
2007-04-04 08:18:28 EDT
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. |