Community
Participate
Working Groups
When the user has a large number of projects (> 150), working sets become very important to be able to scope the working environment. However, it is difficult to define all of the working sets. If it were possible to define the working sets in terms of other working sets, it would simplify this task. Use case: A customer has many (> 50) components, each of which are subdivided into 5 tiers. Each of these component-tiers corresponds to a project. At development time, it is useful to look at a component, a tier, and other groupings. (Related to bug 37032)
Reassigning to Nick since he is taking ownership of this component.
Created attachment 8340 [details] Patch for org.eclipse.ui.ide (part 1 of 2)
Created attachment 8341 [details] Patch to org.eclipse.ui.workbench (part 2 of 2) These 2 patches must be applied together. They provide an implementation of a new kind of working set called a ProjectWorkingSet. Please see the comments in the java class header for ProjectWorkingSet in the ui.ide project. In summary, ProjectWorkingSets hold either top-level projects or nested ProjectWorkingSets. This allows users to create very simple working sets that function for at the right level for basic project organization. Nested sets can have cycles and are evaluated lazily when their "contains" method is called, e.g. for filtering. They are persisted with the existing working set types. There are two new working set classes and their associated persistance factories. The working set extension point is extended to include this working set type. The base class WorkingSet needed it's "restore" constructor made public visible instead of package visible so that the new ProjectWorkingSet could live outside of Workbench. I hope I put everything in the right place. Once this functionality is committed, I will open a bug against the package explorer and other views that do not make use of IContainmentAdapter. The navigator presently uses this and works with the new ProjectWorkingSet "as-is". The only thing missing, that I know of, is a proper reference for Help, which I am looking at now and will create another patch for.
Nick, could you please have a look at these patches as a contribution? Let's discuss what you think and commit them at your earliest convenience. I'd like to also patch the Explorer and possibly the CVS. Thanks, Chris
I can have a look at this on Tuesday at the earliest. Note that WorkingSet is not API to begin with, so it should not be referred to at all from outside the Workbench. IWorkingSetManager.createWorkingSet (IMemento) was added in 3.0 on request from the Debug team for restoring a working set. Can you use this instead?
Nick, thanks for the comments. You can wait until I post another patch that will address your points about the API, probably not until after the integration build. Thanks for your time on this. -Chris
Chris, let me know when there's an updated patch to look at.
Nick, thanks for the note. I have been pondering a bit about the decision to introduce a new kind of working set. When we first discussed it, John and I thought it would be good to have a simple, project-level working set that could be used by the masses to organize large projects. This is a good thing. However, it may cause some confusion for users by having yet-another kind of set. One of my motivations was to have a simple UI. Hopefully, you've had a chance to try it out and observe the UI to be very friendly for creating working sets, even when there are lots of projects in your workspace. I didn't know how to base my nestable working set concept on top of the Resource working set and still have a nice UI. One way might be to extend the Resource working set to allow the "set reference" that points to other working sets. We could put some extra identification on a resource working set that is purely for UI to decide which wizard to use for editing purposes. The rest of the system wouldn't know the difference and everything would just work nice. When creating new Resource working sets, we would need a way to distinguish what kind of UI to use; after that, we could use the extra identifier information for editing them. I don't have a plan yet for the extra identifier or even if it's practical or possible. I'd appreciate anyone's comments on these points. Thanks, Chris
Chris, sorry I did not check out the previous patch since you told me to wait for an updated one. I won't have the time to look at this between now and M8, unfortunately. Keep in mind that there's nothing magic about the resource working set though. JDT defines their own kind of working set for Java elements. If it makes sense for you, you can define your own project-level working set, with nesting, and with its own UI, and ignore the resource working set.
Nick, in response to comment #5, I see why the debug team wanted the createWorkingSet api. They needed a way to recreate working sets without having to know what kind of working set they were dealing with. However, that API just calls the real factory and thus it's infinite recursion if I try and use it to do the work of restoring a working set. I will need to copy the working set class out of workbench, into IDE for the new Project working set type. Also, if you don't look at this until M9, then I'm bummed because I wanted to get new features in by M8. I think the code is clean, so please try if you can. I wish I could help in UI land to take some pressure off, but I'd be a while getting up to speed.
Created attachment 8599 [details] patches org.eclipse.ui.ide Replaces previous patches to add Project Working Sets to the IDE plugin. WorkingSet was copied without any changes from Workbench, which means there is probably a need to refactor and share.
Chris, sorry this fell off my radar after M8. What is the status?
John made it sound like this feature may not make it into 3.0 because of the bad schedule crunch on the UI team. There was also some talk about wanting to implement that nested sets using Resources instead of the Project sets that I built here. Although I'm not working at IBM longer, John was supportive of my involvement with Eclipse and I'd like to keep contributing if I can. So, I guess you'd better check with him on the status of this bug and wether it's going into 3.0 "as-is" or with nested Resources. I'd be happy to re-write it using Resources if that gets agreement; I just don't want to thrash on it :-) Hope you're hanging in there!
not for 3.0. We should look at this immediately after 3.0 completes.
OK, marking as LATER for post-3.0.
This relates to "Large-scale workspaces" (bug 71128). Should it be reopened for 3.1?
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
