Community
Participate
Working Groups
build I20050303 + latest from head Stefan asked me to log the following as a PR. I noticed that BasicStackPresentation.selectPart sometimes sets focus, contrary to its spec. selectPart should only select the appropriate tab (or whatever the affordance is for selecting different parts) and show the corresponding part with updated bounds. This is needed so that a view can be shown but not activated (see IWorkbenchPage.showView(String, String, int). There are three cases that need to be handled: 1. A new part is opened via showView. Should it be given focus, and who's responsible? 2. The user clicks on the tab (or whatever) in the presentation so the new part should be activated. Who's responsible? 3. The user clicks on the part's control (or descendant), giving it focus. The presentation needs to be told that it is active (and if another presentation is active, it needs to be deactivated). Actually, this should work the same whether or not the part's control actually takes focus (e.g. the empty Outline case, where it's just a Label). SWT's Activate event handles both these cases. This can presumably all be handled by the Workbench, and the presentation just be notified via setActive. And in this case, the presentation should not change focus from where the user clicked. There is probably a subtlety here if the part's control doesn't actually take focus. Focus should not be left in the old part in this case. But this could also be handled by the Workbench.
I believe the following is desirable: 1. Focus should be set by the workbench when opening a view. 2. I suppose this is open for discussion, but I think it would be reasonable for the presentation to set focus when the user clicks on some presentation-managed control (like the tabs or chevron). 3. I agree that the workbench should handle this case.
Is this still M8 critical?
There are still some focus problems, but we'll live with them for M8. Should address them all for M9. Let's use this PR as the gathering point and mark specific PRs as blocking this one.
Pointing out the obvious but I think our plan here needs to (where appropriate) do exactly what 2.1 did. Obviously somethings are new but the goal is for things that are part of 2.1.x they should remain the same.
Found another issue: In response to a part's control gaining focus, PartPane.requestActivation calls page.setActivePart, but this results in part.setFocus() being called. This should only be called when switching parts via other means than clicking within the part itself.
Need to finalize this for RC1.
Note: we need to deal with the case where the active part is closed. Currently, we temporarily move focus to a bogus widget until the next part in the activation list becomes active and grabs focus. This degrades performance, causes flicker, blah, blah, blah. It isn't a regression (Eclipse 2.1 used this pattern too), but the pattern is wrong. There should be exactly one focus change when you close a part.
remove 59511 as a blocker for this as it is a separate bug.
nick can we close this?
Yes. If there are further focus problems, we'll open new PRs.
Closing.
