Community
Participate
Working Groups
Since perhaps M7, minimizing an editor stack just shrinks the editor area to a perhaps 640/480 overlay.
The minimize is happening correctly, but the 'fast view' is staying open. I thought this was the expected behaviour, but it does differ from other views.
Reducing severity as clicking anywhere outside of the 'fast view' editor will fully minimize it. I can look at this for the next release.
I think this is a major regression. I've been using Eclipse for years and never had to click away (useless to me) fast views whenever I rearrange my screen.
When any part is minimized, we call requestActivation() on the part service. A comment in the code indicates the intention here is so the minimized part will not be considered activated and pressing the toolbar item will pop open the view. However, the activation is not necessary to pop open the view (on the other hand, giving focus to the next part in the history makes for a better workflow than no part being active). If you have two or more editors open, the part that the part service tries to activate will be another editor. Calling activate on the editor will open it. The solution is probably to put some extra knowledge into the MinMaxAddon. When minimizing the shared editor area perhaps we can request a part not in the shared editor area to activate. Another option would be to skip the part activation entirely if the shared editor area is being minimized. Nothing would be active if the editor area was minimized, which isn't perfect, but better than the current behaviour. Marking for 4.3.1 consideration. I think any change to activation is too risky in RC3, but it is a significant enough fix to include in SR1.
Ah! "activation" IMHO, e4 needs a radical analysis and redesign to re-instate the very distinct behaviours associated with Views and Editors on 3.x. I have lost track of the number of activation related bugs I'm involved in, and I see new ones every week. (Today I click in an Eclipse Tree Editor and Thunderbird activates!!!!!!)
This bug has likely been addressed by the changes to fix bug 371598. While the initial minimize of the editor area still results in the stack opening on the minimize everything else should be working normally now...
Ed (or anyone else..;-), if you could try out in tomorrow's I-build and post some feedback I'd appreciate it...
(In reply to comment #7) > Ed (or anyone else..;-), if you could try out in tomorrow's I-build and post > some feedback I'd appreciate it... I tried an update but got: Your original request has been modified. "Eclipse SDK" is already installed, so an update will be performed instead. "Eclipse SDK" is already installed, so an update will be performed instead. "Eclipse SDK" is already installed, so an update will be performed instead. "Eclipse SDK" is already installed, so an update will be performed instead. "Eclipse SDK" is already installed, so an update will be performed instead. "Eclipse SDK" is already installed, so an update will be performed instead. Cannot complete the install because of a conflicting dependency. Software being installed: Eclipse Platform SDK 4.4.0.I20130717-1600 (org.eclipse.platform.sdk 4.4.0.I20130717-1600) Software being installed: Eclipse Platform SDK 4.4.0.I20130723-0800 (org.eclipse.platform.sdk 4.4.0.I20130723-0800) Only one of the following can be installed at once: Eclipse Platform SDK 4.4.0.I20130709-0800 (org.eclipse.platform.sdk 4.4.0.I20130709-0800) Eclipse Platform SDK 4.4.0.I20130717-1600 (org.eclipse.platform.sdk 4.4.0.I20130717-1600) Eclipse Platform SDK 4.4.0.I20130702-1230 (org.eclipse.platform.sdk 4.4.0.I20130702-1230) Eclipse Platform SDK 4.4.0.I20130625-0800 (org.eclipse.platform.sdk 4.4.0.I20130625-0800) Eclipse Platform SDK 4.4.0.I20130723-0800 (org.eclipse.platform.sdk 4.4.0.I20130723-0800) Eclipse Platform SDK 4.4.0.I20130618-0800 (org.eclipse.platform.sdk 4.4.0.I20130618-0800)
(In reply to comment #7) > Ed (or anyone else..;-), if you could try out in tomorrow's I-build and post > some feedback I'd appreciate it... I'm not sure I'm using the right steps, but I can't reproduce "it" with R4.3 (official Kepler release) or latest N-build (N20130729-2000). My Steps: 1. start new workspace 2. close Welcome page 3. paste the following into the 'Package Explorer': public class C {} 4. click the 'Minimize' button of the shared/editor area ==> shared/editor are gets minimized as expected and 'Package Explorer' has focus Ed, if you can still see this, or this bug is about different steps, then please comment here. Otherwise this looks like WORKSFORME.
As Eric points out in comment #6, the original problem, that minimizing an editor doesn't minimize the fast view, is still broken. I confirmed this in I20130730-0800. Dani, to reproduce you need multiple editors. If you do, the stack will minimize, but open as a fast view. The active editor will change, which is even more distracting.
(In reply to comment #10) > As Eric points out in comment #6, the original problem, that minimizing an > editor doesn't minimize the fast view, is still broken. I confirmed this in > I20130730-0800. > > Dani, to reproduce you need multiple editors. If you do, the stack will > minimize, but open as a fast view. The active editor will change, which is > even more distracting. Isn't it nice to have simple steps? ;-). Test Case: 1. start new workspace 2. close Welcome page 3. paste the following into the 'Package Explorer': public class C1 {} public class C2 {} 4. click the 'Minimize' button of the shared/editor area ==> bug: shared/editor area becomes an opened fast "view" with C1 active and due to bug 414108 one cannot easily close it by pressing 'Esc'.
Created attachment 234331 [details] Simple fix This patch avoids requesting part activation when the editor area is minimized. It fixes the original issue, but causes another problem. The editor stays active, meaning the status bar still displays editor information and keyboard presses still go to the minimized editor.
Eric, if a part is minimized, should it still return true for isToBeRendered()? When looking for a part to activate in the history, it starts with sibling editors. The history checks if the next part is to be rendered, but not whether it is visible or not. If minimizing doesn't change its to be rendered setting, then we may have to look at changing PartServiceImpl to allow restricting the sibling editors. We need some way of saying "activate a different part, but it can't be a sibling to the active part"
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=74f064e095b6118334f3be864b4827d4bc97ed6a Fixed in master. I will clone to backport. The problem is related to my last commment. We are not validating the part to activate if we are looking at siblings. Since views in the same stack are not considered siblings, the code would always use findActivationCandidate(), which checks if each candidate is valid. The editors are siblings (belonging to an MArea), so they are checked if they are to be rendered, but not if they are valid. The fix is very simple and fixes more scenarios than comment #11 steps. for example, when two editors are in a fast view, pressing the escape key will switch editors, rather than close the fast view.
(In reply to comment #14) > The fix is very simple and fixes more scenarios than comment #11 steps. I hope so. There are plenty of wierd things that could correlate, like backward/forward arrow between editors sometimes needing two forwards to revert one backward.
Verified in I20130813-1330.
