Community
Participate
Working Groups
When switching from Debug perspective to Java, the file that last had focus/was active in the Java perspective is again active. I expect the active editor to be the one that was active in the debug perspective. This is very irritating as I have to take an extra action to get to where I was in the Debug perspective. When I shift back to the Debug perspective, in the other direction (from Java to Debug), the debug perspective shows the tab that was active in the Java perspective. I now have to go the Debug view, find the thread again, and double click to get the editor tab for "where I was". (Perspective shift is done with the buttons in the upper right.) This is a major usability issue as it disrupts the flow of thought.
I think this is caused by the fact that double clicking in the Debug view does not bring focus to one of the tabs, but it shifts the editor view to make it visible. If I click on the editor tab (to make it active) before switching perspective it works as I expect. But this is very easy to forget as some operations in the Debug view make the editor tab become non-active. Confusing...
The editor area (or shared area in 4.2) is shared among perspectives of the same window and hence the active part remains the same. This is by design and works like that since 2.0. If you want to separate the editors, you can open a new window and keep one perspective per window. You can let that happen automatically if you change the settings on the General > Perspectives preference page.
You describe how I want it to work - it is a shared area and the active file is active in all perspectives. What I am saying is that this is often not the case when debugging. Click on a position in a Debug view thread - opens the editor tab but does not make it active. Switch perspective and you are someplace else.
(In reply to comment #3) > You describe how I want it to work Good :-) What version are you using? If you use 4.2, can you test with this one: http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/
(In reply to comment #4) > (In reply to comment #3) > > You describe how I want it to work > > Good :-) > > What version are you using? If you use 4.2, can you test with this one: > http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/ Tried 3.8, it works as it should. But 4.2 does not. To see the problem; make the debug perspective shift current tab by an operation in the Debug view - then switch perspective (without clicking in any editor or other view). Then shift perspective back again to debugging. (I think that is enough).
This is a general problem not related to debugging: if the active editor is not the active part and one switches to another perspective where previously an editor was the active part, then it makes that editor active again. Steps that don't involve debugging: 1. start 4.2 or latest 4.3 with a new workspace 2. create a project with two files 'f1' and 'f2' in it 3. open both files, so that 'f2' is active 4. switch to the 'Resource' perspective 5. in the 'Project Explorer' enable 'Link with Editor' 6. in the 'Project Explorer' click on 'f1' ==> 'f1' is the active editor but the 'Project Explorer' is the active part 7. switch back to the 'Java' perspective BUG: 'f2' gets activated instead of 'f1'.
*** Bug 395005 has been marked as a duplicate of this bug. ***
This is a regression in E4. Please increase priority.
We should try to address this for 4.3.1.
CQ:WINDE4BLOCKING
I'm going to work on it just after I finish other stuff. However if someone fills like: "it is sth that I always wanted to fix and it is proper time to do it" fill free to reassign it, Daniel
Daniel, I decided to take this since I had a fix in mind... Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ed56e288c57b9ae0e3728f3fd05ae69e124c83d3 ** IMORTANT ** This commit *removes* the PartServiceImpl's 'setPart' method. This means that controlling the active part *must* take place through a specific call to the 'activate' method. Any existing code that tries to modify the active part through manipulating the context will no longer get recognized. I haven't found any new issues resulting from this. It was necessary because under the defect's scenario I kept getting the Project Explorer to open in my Java perspective (as well as getting the editor switch). Keep an eye out for issues and re-open if you encounter problems related to mis-activations (missing keybindings...).
This caused 31 test failures in the build [1]. Please run the tests locally before committing changes to 'master' ;-).
(In reply to comment #13) > This caused 31 test failures in the build [1]. Please run the tests locally > before committing changes to 'master' ;-). [1] http://download.eclipse.org/eclipse/downloads/drops4/N20130826-2000/testResults.php
<Sigh> Sorry, I'm looking at them now...
OK, Here's a much more surgical commit http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dbe52ea257676877591014234d296d3465793bd2 ...all tests green...;-) I've opened Bug 415987 to work on the remaining issue of the mysteriously appearing Project Explorer (which I get when switching back to the Java perspective in the defect scenario).
Marking FIXED... Note that this fix does *not* handle the case where the editors used are in different stacks...
(In reply to comment #16) > I've opened Bug 415987 to work on the remaining issue of the mysteriously > appearing Project Explorer (which I get when switching back to the Java > perspective in the defect scenario). That seems to be the wrong number.
The test results are green in I20130829-2000. I also verified that it fixes the bug using the steps from comment 6. However, while doing so, I found an even worse issue: when switching back to the 'Java' perspective, it gets "polluted" with the 'Project Explorer'! I filed bug 416235 to track the new issue.
