Community
Participate
Working Groups
build I20040318 When a view is active, the editor workbook still looks active. Previously in 2.1 and M7, the selected editor's tab would lose the gradient (though it would still be indicated as selected, using a white background). This is an important cue. You're in a fundamentally different mode when in a view vs. an editor. One obvious difference is how keybindings work. I've had several "loss of context" experiences lately where I've wanted to do Ctlr+O or Ctrl+Shift+B, and they don't have any effect. I then have to figure out that my focus was in a view, not the editor.
I think this should be an M8 candidate.
*** Bug 54875 has been marked as a duplicate of this bug. ***
*** Bug 55506 has been marked as a duplicate of this bug. ***
i have changed this to ensure that for the 'third state', the editor looks 'inactive' instead of 'active'. this should be a big improvement until we can reintroduce the 3rd state properly.
*** Bug 59166 has been marked as a duplicate of this bug. ***
Stefan, can you provide any insight as to where in the presentation logic this would best reside? Would it reside lower in EditorWorkbook?
NOTE, views should also have a third state, it occured to me that when the whole shell (i.e. WorkbenchWindow) loses focus to another one, the tabs on the views should appear in the COLOR_TITLE_INACTIVE_* style to match the shells title bar. so we have editors with a third state where they are the active editor but not the part that has focus at the moment, and then whether it is an editor or a view the active part should have the INACTIVE colors when the shell is not in focus.
For me it looks like this is best implemented below the presentation to have a clean concept for all presentations. The StackPresentation#setActive(boolean) needs to be changed to StackPresentation#setActive(int) for passing different states into it. The old 2.1 style implementation of EditorWorkbook has such a method with the following states: ACTIVE_FOCUS ACTIVE_NOFOCUS INACTIVE Internally it checks for: WINDOW_SHELL_ACTIVE WINDOW_SHELL_INACTIVE if the passed in state is ACTIVE_FOCUS.
I also noticed that EditorPane#shellActivated/shellDeactivated is commented out. Maybe this can be used to inform the StackPresentation about state changes when the shell changes state. (The calling shell listener is registered in WorkbenchWindow#trackShellActivation).
Yes, the workbench should respond when the shell is deactivated, and Gunnar's comments are accurate. This is a regression. But this is also independent of the editor workbook's "3rd state".
Bouncing to Stefan for required presentation UI. Please bounce back when you're finished.
Gunnar's suggestion in comment 8 sounds reasonable. The new API has been added to head. A new StackPresentation.setActive(int) has been added, and StackPresentation.setActive(boolean) has been deprecated. There are now 3 states, but the 3rd state is currently only used by editors. If views or editors want to change their appearance based on shell activation, they can use a Shell listener (no additional states will be added for this). Note: when Kim first suggested this, I expressed some concerns about detached views... however, I now believe that this will not be a problem. The shell listener should work fine for all cases. Also note: there are still unresolved activation bugs which may cause problems with the 3rd state. If you ever observe an invalid state (nothing showing focus, two things active, no active editor, etc.) please file a bug. Bouncing back to Kim
Fix in HEAD.
Verified against 200405180816
Closing to keep a tidy house. Pardon the spam.
