Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319285

Summary:	Tab folders do not stay coloured when switching between workbench windows
Product:	[Eclipse Project] e4	Reporter:	Remy Suen <remy.suen>
Component:	UI	Assignee:	Project Inbox <e4.ui-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	ob1.eclipse
Version:	1.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:	stalebug

Description Remy Suen

2010-07-08 12:32:06 EDT

1. Activate a part. See that its tab folder is blue.
2. Window > New Window
3. Move the new window (if necessary) and see that the tab folder of the previous workbench window is now no longer highlighted in blue.

The WBWRenderer styles part stacks based on the active part that it is injected with. Unfortunately, the problem with this approach is that it has no regard of the concept of windows. It is always being injected with the active part as known by the application.

Hence, when you switch workbench windows, the active part as perceived by the application changes. The renderer recognizes this change and unsets the highlighting of the tab folder of the previously active part so its colour goes white even if it still technically the active part in that other workbench window.

Comment 1 Eric Moffatt

2010-07-09 13:53:50 EDT

IMO the active part is *window based*, having it in the App's context is bogus. We should be setting the active part in the top level window's context as a straightforward value (not a computation, RAT or whatever) and re-examine the code that has lead to its being forced into the wrong place...

Comment 2 Remy Suen

2010-07-09 13:58:16 EDT

(In reply to comment #1)
> re-examine the
> code that has lead to its being forced into the wrong place...

Which "wrong place" do you speak of exactly?

Regardless of what happens, the code that's in WBWRenderer needs to be shifted elsewhere or compensate for the fact that there are "multiple" active parts.

Comment 3 Oleg Besedin

2010-07-09 14:28:57 EDT

(In reply to comment #2)
> (In reply to comment #1)
> > re-examine the
> > code that has lead to its being forced into the wrong place...
> Which "wrong place" do you speak of exactly?

Let me add from the top of my head:

- bug 283473 
- the bug where copy/paste goes to a wrong workbench window (don't have the number handy)
- to a degree, bug 315270 and the need for the shell activation listener

The combination of ActivePartLookupFunction -> PartServiceCreationFunction -> PartServiceImpl creates a code with "butterfly effects": little changes to, say, ActivePartLookupFunction, or even to the order in which PartServiceImpl objects are created behind the scene lead to surprising changes in the application's behaviour.

I am not convinced that we can (or should) change this two weeks before the release, but yes, IMO, the Active Child, Active Part, and Part service code need to be changed into something much more straightforward.
(For instance, I was surprised to discover when exactly part services are created and even more surprised to discover how they tied together through propagation of active children.)

(By the way, the model is not perfect in this area as well - the #setSelectedElement() duplicates active child with no clear rules on the order or precedence.)

Comment 4 Eclipse Genie

2018-10-17 20:23:16 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 5 Lars Vogel

2019-06-05 07:40:11 EDT

This is a mass change to close all e4 bugs marked with "stalebug" whiteboard.

If this bug is still valid, please reopen and remove the "stalebug" keyword.