Community
Participate
Working Groups
Focus is not handled cleanly on some perspectives. For example, if I select a class and then "run" it, when I'm done and come back to the Java perspective, the class is highlighted, but no longer has focus. This forces the user to used a few extra mouse clicks and can be frustrating. Another example: I run an application, which happens to bring up the Debugging Perspective. I see a problem, so I decide to debug. I use the debug button to select debugging the application. I invariably get a "no Java application found" message because focus has been lost on the class that contains main. This forces me to switch back to the Java Perspective, select the class again, then select debug.
The problem is addressed by the relaunch action. We need to revisit the focus sensitivity of run when doing launch configs. Hopefully, we are less focus sensitive then. Moving to Debug FYI.
Launch configurations work differently. The workbench selection is considered when creating a new config, but not when re-lanuching. Re-launching is a different action - you can use F9 to relaunch last, or use the debug/run history.
I'm not sure, but it looks like this original issue got lost here. A user can have any number of perspectives open at any given time. When you go between these perspectives, whatever had focus when you left should still have focus when you return. This is especially true if the item is highlighted, giving the false impression that it is in focus.
Nick, is this a workbench issue? I.e. when a dialog opens and closes, the workbench focus should not be lost - it should not be up to the dialog to handle this?
I believe David was referring to simply switching perspectives, not dialogs. Focus should certainly be preserved for dialogs, and this is apparently correctly handled. As for perspectives, views and editors are shared across perspectives in the same window. When switching perspectives from A to B, we try to activate the same part as was active in A. If there is no such part in B, the result is that no part is active. The case described here sounds like the Debug view is active, so when you switch back to the Java perspective, nothing is active. We could definitely improve on this. The perspective could remember the active part, and reactivate it when the perspective is reactivated. Or, we could do a hybrid approach, whereby we keep the same part active if it's present in both perspectives, or restore the previously active part if not.
Reassigning to UI team.
One of the requirements from the usability group is if the active part in Persp A is present when switching to Persp B, then it should keep the focus. When it does not exist, we could try activating the past last used in Persp B the last time the user switched to it.
This makes sense to me.
The current discussion sounds like it is going in the right direction. I think the annoying thing is when you click on something and do something with it, then have to click on it again. If something else had focus in the perspective, it would be different. In most cases I've encountered, though, there isn't any focus. The user is left wonder why they have to click on something they just clicked on. Kind of like web pages where the only obvious thing is to type in a text box, but you have to click in it first.
Defer until after release 2.0
Reopen for investigation
Reassigning bugs in component areas that are changing ownership.
Is this still a problem in 3.3? PW
I haven't run 3.3. In fact, I haven't run Eclipse at all for quite some time. So, I don't know if it works now or not.
The code governing perspectives, window activation, and editor focus has all been re-written twice since 2.0 :-) PW
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
