Bugzilla – Full Text Bug Listing
| Summary: | [Wizards] Newly created projects should be added to the active working set | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Sam Davis <sam.davis> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, hsoliwal, prakash |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
Sam Davis
Note that this works when creating a new 'Java Project' but not when creating a general or PDE project. When moving the report to another component, the assignee needs to be reset to the default. (In reply to comment #1) > Note that this works when creating a new 'Java Project' but not when creating a > general or PDE project. It also doesn't work (even for Java projects) when a task working set is selected. (In reply to comment #3) > (In reply to comment #1) > > Note that this works when creating a new 'Java Project' but not when creating a > > general or PDE project. > > It also doesn't work (even for Java projects) when a task working set is > selected. Talking for Java Project: then the task working set are maybe somewhat special (they are not part of the SDK). You should file a separate bug with Mylyn. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > Note that this works when creating a new 'Java Project' but not when > creating a > > > general or PDE project. > > > > It also doesn't work (even for Java projects) when a task working set is > > selected. > Talking for Java Project: then the task working set are maybe somewhat special > (they are not part of the SDK). You should file a separate bug with Mylyn. I did that (see description) and was told it's a limitation of the platform.... (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #1) > > > > Note that this works when creating a new 'Java Project' but not when > > creating a > > > > general or PDE project. > > > > > > It also doesn't work (even for Java projects) when a task working set is > > > selected. > > Talking for Java Project: then the task working set are maybe somewhat special > > (they are not part of the SDK). You should file a separate bug with Mylyn. > > I did that (see description) and was told it's a limitation of the >platform.... Well, you reported a different issue here than Steffen labeled a "platform limitation". There are two problems: 1) This bug: New Simple/PDE Project wizards not adding the new project to the active working set like JDT does. 2) Platform not showing the Mylyn Task working sets. This is a separate bug that Mylyn should try to resolve to together with the Platform UI if they are interested. We have been here before. I couldn't get the bug numbers though. From what I remember, there were two issues. 1) The "current active working set" is relative to what you are doing. Say you are on Package Explorer; it could a Java working set, you are on Breakpoints View, it could be Breakpoint working set; if you are on Project Explorer it could be a Task & Resource working set & so on ... 2) To find out what are the working sets that are applicable for a project (like you can't add plain Java project to Plugins & Fragmenets working set) you would need a errrr, a Project. When you are at the new project wizard, the project is not yet created, so currently there is no way to find out the applicable working sets. See Bug# 262933 (In reply to comment #7) > We have been here before. I couldn't get the bug numbers though. > > From what I remember, there were two issues. > > 1) The "current active working set" is relative to what you are doing. Say you > are on Package Explorer; it could a Java working set, you are on Breakpoints > View, it could be Breakpoint working set; if you are on Project Explorer it > could be a Task & Resource working set & so on ... > > 2) To find out what are the working sets that are applicable for a project > (like you can't add plain Java project to Plugins & Fragmenets working set) you > would need a errrr, a Project. When you are at the new project wizard, the > project is not yet created, so currently there is no way to find out the > applicable working sets. Right and my comment 1 was not fully correct: this only works for concrete working sets (not window ws) and only when the Java project is created while the Package Explorer is active. (In reply to comment #7) > We have been here before. I couldn't get the bug numbers though. > > From what I remember, there were two issues. > > 1) The "current active working set" is relative to what you are doing. Say you > are on Package Explorer; it could a Java working set, you are on Breakpoints > View, it could be Breakpoint working set; if you are on Project Explorer it > could be a Task & Resource working set & so on ... But the window working set is not relative to what you are doing, right? The window workingSet is only an aggregate of other workingSets, and hence returns the collection of adaptables that are contained in its component sets. If they are no containing sets, then for a given context "all" is the expected behaviour. Observe that the user is allowed(via the toolbar and menubar) to add or remove other workingset only (and not IAdaptables, setElements is a noop in this case). As an example, the project explorer shows all projects in a workspace when configured with an empty window workingSet, while the problems view would show problem markers across the entire workspace. Hitesh,
In a New * Project wizard, where we have not yet created the project, how do we determine the supportedWorkingSetTypes parameter for the WorkingSetGroup?
Why does that have to be done before the project is created? Currently I get a dialog after creating the project asking me if I want to disable the working set to reveal the project - couldn't the instead dialog ask me if I want to add the project to the working set (or just silently add it)? (In reply to comment #13) > Why does that have to be done before the project is created? Currently I get a > dialog after creating the project asking me if I want to disable the working > set to reveal the project - couldn't the instead dialog ask me if I want to add > the project to the working set (or just silently add it)? ... to which working set? How can Platform UI determine the current working set? Based on the active view? If so, how do we get the active working set from the active view? I don't think there is an API at present. My understanding is that the window working set doesn't depend on which view is active. If the window working set "contains" exactly 1 working set, and the new project can be added to that working set, I would think that it should be. If the window working set contains multiple working sets, perhaps there should be a dialog allowing the user to choose among them (the new project would be added to the chosen working set, or none if the user so chooses). (In reply to comment #15) > My understanding is that the window working set doesn't depend on which view is > active. > > If the window working set "contains" exactly 1 working set, and the new project > can be added to that working set, I would think that it should be. If the > window working set contains multiple working sets, perhaps there should be a > dialog allowing the user to choose among them (the new project would be added > to the chosen working set, or none if the user so chooses). We shouldn't be simply adding a project to a working set. That is why we have the working set selection in the creation wizard. I'm not for the idea of opening up a dialog after the user presses Finish in the wizard. (In reply to comment #16) > I'm not for the idea of > opening up a dialog after the user presses Finish in the wizard. I agree it's not ideal, but I *already* get a dialog after pressing finish in the wizard. At least the dialog could be more useful, and give me the option of adding the project to a working set. (In reply to comment #12) > Hitesh, > > In a New * Project wizard, where we have not yet created the project, how > do we determine the supportedWorkingSetTypes parameter for the WorkingSetGroup? We need an instance of IAdaptable to ensure that a given object is compatible with a given workingset (as explained in Bug# 262933 ). However, the resources workingset should accept a project. The bug appears to face the same fate as Bug 262933, unless someone has a better way to work around it :) Perhaps one option would be to simply list "window working set" in the New Project wizard under working sets, without checking whether it is applicable to the project being created, and then, after the wizard completes, display a dialog to the user only if the project could not be added. I would guess that the vast majority of users would never have to see that dialog. (In reply to comment #18) > >In a New * Project wizard, where we have not yet created the project, how > >do we determine the supportedWorkingSetTypes parameter for the WorkingSetGroup? > > We need an instance of IAdaptable to ensure that a given object is compatible > with a given workingset (as explained in Bug# 262933 ). However, the resources > workingset should accept a project. That is the whole problem. We don't have an IProject or an IAdaptable, as the project is *not* created until the user clicks the Finish button in the wizard. It would be really helpful if I get a snippet showing how to get the list of workingset ids for a project that doesn't exist yet. (In reply to comment #19) > the project being created, and then, after the wizard completes, display a > dialog to the user only if the project could not be added. I don't agree with this. We already present the user with the working set control in the wizard. The user chooses not to add it to any working set and then after he presses Finish, we popup a dialog and ask him whether we want to add the project to any working set. The correct way is to pass the supportedWorkingSetTypes with the right list of ids - neither hardcoded ones nor all the ids. To do that either (1) I need an API from the WorkingSet - doesn't seems to be happening from Bug# 262933 (2) or at least someone enlightens me with a snippet, that it is possible to do it the with the existing APIs (The code is available in BasicNewProjectResourceWizard.addPages()) Unless (1) or (2) happens, I don't see this bug going anywhere This discussion is getting confusing, partly because I didn't understand the issue very well when I started it, so I'm going to summarize the current situation as I see it now, if only for my own benefit: # The JDT new project wizard's working set control autoselects the working set that is filtering the package explorer, but only when the package explorer is the active view # Other new project wizards do not have this behaviour # No new project wizards have any support for adding the new project to the window working set # The JDT new project wizard, pops up a dialog _after the user clicks finish_ asking if they want to deselct the current working set, if the project was not added to it. # Task working sets do not show up in those working set controls. That's a separate issue so let's ignore it. I do not believe the behaviour described in 1) makes much sense. Whether the package explorer happens to be active when you click the new project button should not determine the selection in the working set list in my opinion. I think that the working set control in all new project wizards should have an option to add the project to the window working set, and this should be selected by default. The whole point of a window working set is that it applies to all views and controls. Apparently it is not possible to know whether the window working set is of the right type for the project before the project is created (even though somehow the list is populated with other working sets that are of the right type), so in the event that the window working set turns out not to be of the right type, the project would simply not be added to it. (In reply to comment #22) > # The JDT new project wizard's working set control autoselects the working set > that is filtering the package explorer, but only when the package explorer is > the active view Yes, thats because the wizard knows both about the view and the java working set. > # Other new project wizards do not have this behaviour Because, for a wizard, there is no way to know what are the working sets supported in the currently active view > # No new project wizards have any support for adding the new project to the > window working set That could be raised as a separate bug, so that Window Working set is shown in the list of available working sets > # The JDT new project wizard, pops up a dialog _after the user clicks finish_ > asking if they want to deselct the current working set, if the project was not > added to it. > # Task working sets do not show up in those working set controls. That's a > separate issue so let's ignore it. Again because JDT knows nothing about the other working sets that are capable of holding the Java projects - and there is no way at present to find it from the wizard (In reply to comment #23) > (In reply to comment #22) > > # No new project wizards have any support for adding the new project to the > > window working set > > That could be raised as a separate bug, so that Window Working set is shown > in the list of available working sets Is that really a separate bug? The original summary for this bug was "Newly created projects should be added to the _window working set_" If that's a separate bug, then I don't know what this bug is about! (In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > # No new project wizards have any support for adding the new project to the > > > window working set > > > > That could be raised as a separate bug, so that Window Working set is shown > > in the list of available working sets > > Is that really a separate bug? The original summary for this bug was "Newly > created projects should be added to the _window working set_" If that's a > separate bug, then I don't know what this bug is about! As I see now the summary states "active working set" not "window working set" (In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > (In reply to comment #22) > > > > # No new project wizards have any support for adding the new project to > the > > > > window working set > > > > > > That could be raised as a separate bug, so that Window Working set is shown > > > in the list of available working sets > > > > Is that really a separate bug? The original summary for this bug was "Newly > > created projects should be added to the _window working set_" If that's a > > separate bug, then I don't know what this bug is about! > > As I see now the summary states "active working set" not "window working set" Yes, somebody else changed that. Let me reiterate that I do *not* think that new projects should be automatically added to the working set of whichever view happens to be active. I think that behaviour would be quite confusing, as I would never deliberately activate a particular view before creating a new project. >I don't agree with this. We already present the user with the working set >control in the wizard. The user chooses not to add it to any working set and >then after he presses Finish, we popup a dialog and ask him whether we want to >add the project to any working set. I agree with Prakash. > I do *not* think that >new projects should be automatically added to the working set of whichever view >happens to be active. It depends on your workflow. If you are in the Project or Package Explorer and create a new project then you'd probably want that project to appear i.e. be part of the view's currently active working set(s). Therefore, I don't think the discussion needs to be tied to the window working set but rather the "active" working sets (which could be the window working set). If the new project wizards would allow to choose that and if they would store the last chosen values then that would be a good solution to your problem. Once could also decide to only solve the original problem by adding a 'Window Working Set' to the list. (In reply to comment #27) > Therefore, I don't think the discussion needs to be tied to the window working > set but rather the "active" working sets (which could be the window working > set). If the new project wizards would allow to choose that and if they would > store the last chosen values then that would be a good solution to your > problem. Once could also decide to only solve the original problem by adding a > 'Window Working Set' to the list. Right. So the solution is two fold: First is the wizard shows up the appropriate list of working sets in the wizard itself, so that the user selects there (which I'm tracking in this bug). Second is the Window Working set itself appears in that list. The control is generic and could be embedded outside a WizardPage also. So best to track that separately. Raised Bug# 332496 for that. (In reply to comment #27) > >I don't agree with this. We already present the user with the working set > >control in the wizard. The user chooses not to add it to any working set and > >then after he presses Finish, we popup a dialog and ask him whether we want to > >add the project to any working set. > I agree with Prakash. > > > I do *not* think that > >new projects should be automatically added to the working set of whichever view > >happens to be active. > It depends on your workflow. That seems like a good reason not to have that behaviour, or at least, not to make it the default. > If you are in the Project or Package Explorer and I don't think you can tell when the user is "in the package explorer," meaning looking at and thinking about it. You can tell when the package explorer is active, but that is completely different IMO. > create a new project then you'd probably want that project to appear i.e. be > part of the view's currently active working set(s). I would generally want a new project to appear in the package explorer, regardless of which view was active at the moment I created the project (which is essentially random for me). > Once could also decide to only solve the original problem by adding a 'Window > Working Set' to the list. That is exactly what I would like. :) I think if you have a window working set, it means you are working on a certain thing, and new projects you create are very likely to be related to that thing, so you would want them to be part of the window working set. If you have different working sets active in different views, then it's less clear, but for someone like me who uses the package explorer and not the project explorer, it might make sense to add it to the package explorer's active working set, but that shouldn't depend on the package explorer being active. If you use both the package and project explorers and have different working sets active in them, then I don't think it's clear what to do, but _maybe_ it should depend on which of them was active _most recently_. In general, I don't think having, for example, an editor active, should cause the project not to be added to a working set. Thanks Prakash for rasing the bug. (In reply to comment #28) > (In reply to comment #27) > > > Therefore, I don't think the discussion needs to be tied to the window working > > set but rather the "active" working sets (which could be the window working > > set). If the new project wizards would allow to choose that and if they would > > store the last chosen values then that would be a good solution to your > > problem. Once could also decide to only solve the original problem by adding a > > 'Window Working Set' to the list. > > > Right. So the solution is two fold: First is the wizard shows up the > appropriate list of working sets in the wizard itself, so that the user selects > there (which I'm tracking in this bug). Second is the Window Working set itself > appears in that list. The control is generic and could be embedded outside a > WizardPage also. So best to track that separately. Raised Bug# 332496 for that. (See Comment #11 and Bug 332496 Comment 1) AggregateWorkingSet#setElements(IAdaptable[] elements) is a no-op. See also bug 15941. 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. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |