Community
Participate
Working Groups
- Change the java preferences to "Open a new type hierarchy inside the hierarchy perspective". - Change the workbench preferences to open perspectives in new window. - Press F4 in a few class names to open hierarchy perspectives. In a few minutes of work you endup with a number of windows. All windows will have the same title and that makes it a bit difficult to find them in the Windows taskbar. We should/could change the title to have the class name in the begining so we could see it in the Windows taskbar. NOTES: EG (7/11/2001 12:39:22 PM) should have a spring loaded mechanism to control whether a type hierarchy perspective should be reused.
moved to 'active'
given that we now have a history of inputs, reusing makes a lot of sense. we should have a 3rd preference option: reuse type hierarchy without this option the type hierarchy perspective isn't very attractive you end up with too many of them.
DB is the specialist for the type hierarchy perspective....
... and Dirk has complained about this as well. we should only reuse the type hierarchy inside one workbench page.
This is not possible since there is no API to set the input of a perspective. This leads to the following problem: - window title doesn't update if we reuse the perspective under the cover - the perspective might be reused also it already works on a different hierarchy. Scenario: - open hierarchy on B - open hierarchy on A - switch to not reuse perspective in same window - open hierarchy on B - the hierarchy for A pops to front since because its input element is B, but it is showing the hierarchy for A Bottom line: as long as the platform doesn't provide a method setInput on IWorkbenchPage this is not implementable. Opt to postpone
not for 2.0
Nick, does the workbench think about providing a setInput on perspective. If not please dispose PR.
If we add setInput, then views would have to be able to get notified about the change and update accordingly. Could do this by undeprecating IWorkbenchPage.add/removePropertyListener and define a property for the input.
Please see comments above.
Please see comments above. Q1: Do you want this for 2.1?
Would be nice to get it for 2.1
I agree with Dirk: "nice to have"
Just talked to KH and he says this is a breaking change because views may not expect that the input of a page changes. So, unless you guys object, I am going to defer this once more.
OK to defer
If it is a breaking change it will not go into 2.1. Reducing to P3.
Reassigning bugs in component areas that are changing ownership.
There are currently no plans to work on this feature. PW
Changes requested on bug 193523
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.
